Microsoft Entra ID（旧 Azure AD）の試用環境で、外部ゲストとして招待した自分のアカウントをうっかり「メンバー」に変えた結果、唯一の管理者がポータルに入れなくなる――実はよくある事故です。本記事では「AADSTS160021 / 16000 エラーでロックアウトされたときに何をすべきか」を、仕組みの解説から具体的な復旧手順、再発防止策まで詳しく解説します。
外部ゲスト管理者をメンバー化してロックアウト…何が起きたのか
まずは、今回の典型的なシナリオを整理します。
- 試用中の Microsoft Entra ID（旧 Azure AD）テナントを用意
- 唯一の管理者として、個人用 Microsoft アカウント（MSA） を「外部ユーザー（ゲスト）」として招待
- 後からポータルでその外部ユーザーを「メンバー（内部ユーザー）」に変換
- 以降、Azure Portal や Entra 管理センターにサインインすると AADSTS160021 / AADSTS16000 のようなエラーでログイン不可
- 初期パスワードも控えておらず、サポート チケットも開けない
この時点で「テナントに入れる管理者がゼロ」の状態になり、テナントの設定変更も削除もできない、というつらい状況になります。
| 項目 | 状況 |
|---|---|
| テナント種別 | 試用（Azure / Microsoft 365 の Trial / Developer テナントなど） |
| 管理者アカウント | 個人用 Microsoft アカウント（MSA）を外部ユーザーとして招待 |
| 作業内容 | 外部ユーザーを「メンバー」に変更 |
| 発生した現象 | Azure Portal / Entra admin center へサインイン不可（AADSTS160021 など） |
| よくある困りごと | 初期パスワード不明、SSPR 未設定、他の Global Admin もいない |
では、なぜ「外部 → メンバー」変換だけで、ここまで深刻なロックアウトになるのでしょうか。
原因：#EXT# が消えて UPN が変わり、MSA と切り離される
外部ユーザー（ゲスト）とメンバーの違い
Microsoft Entra ID では、同じ「ユーザー」に見えても、外部ユーザー（ゲスト） と メンバー（内部ユーザー） は性質が大きく異なります。
| 項目 | 外部ユーザー（ゲスト） | メンバー（内部ユーザー） |
|---|---|---|
| 典型的な用途 | 社外パートナー・個人 MSA を招待 | 社内の社員アカウント |
| サインイン元の ID | 元の組織（MSA / 他テナント）の認証 | 当該テナントの認証（Entra ID ローカルパスワード） |
| UPN（ユーザー名）の例 | jane_example.com#EXT#@contoso.onmicrosoft.com | [email protected] など |
| パスワードの管理 | MSA 側、または招待元ではなく元テナント側 | このテナントで設定されたパスワード |
| 変換操作 | 「メンバー」に変換すると UPN が変わる | 「ゲスト」に戻すこともできるが慎重さが必要 |
特に重要なのが「サインイン元の ID」です。外部ユーザーのときは MSA のパスワードで認証していましたが、メンバーに変えた瞬間から「このテナントのユーザー」として扱われます。
#EXT# 付き UPN の仕組み
MSA や別テナントのユーザーを招待すると、Entra ID 内では次のような UPN（ユーザー プリンシパル名）が自動生成されます。
- 変換前（外部ユーザー）：
jane_example.com#EXT#@contoso.onmicrosoft.com - 変換後（メンバー）：
[email protected]
この #EXT# の有無が、想像以上に大きな違いです。
- #EXT# 付き UPN は、「外部ユーザー」であることを示す内部的な識別子
- ゲストのときは、MSA のメールアドレスと裏側で紐付いている
- 「メンバー」に変換すると #EXT# が消え、MSA とは別の「内部ユーザー」として再定義される
つまり、同一人物に見えても、中身としては別アカウントになっていると思ってください。
ロックアウトが起きるメカニズム
今回のロックアウトは、次のような流れで発生します。
- もともと、MSA のメールアドレスでサインイン → ゲスト ユーザーとしてテナントにアクセスできていた
- 管理ポータルで「外部ユーザー → メンバー」に変換
- 内部的に UPN が
xxx#EXT#@contoso.onmicrosoft.com→[email protected]に変更される - 同時に「MSA とのひも付け」が外れ、MSA の認証ではそのテナント ユーザーを見つけられなくなる
- その状態で MSA のアドレスでサインインしようとすると、テナント内に対応するユーザーがいない扱いとなり、AADSTS160021 / 16000 系のエラーが出る
つまり、サインインの問題は「アカウントが消えた」のではなく、サインインしている ID とテナント内のユーザーが別物になってしまった、というミスマッチが原因です。
AADSTS160021 / AADSTS16000 系エラーの意味
このケースでよく見かけるのが、次のようなエラー コードです。
- AADSTS160021
- AADSTS16000
- またはその周辺の 1600x 番台のエラー
エラー メッセージのバリエーションはありますが、ざっくりいうと次のような意味合いのものが多いです。
| エラーコード | よくある意味合い（概要） | 今回のケースでの解釈 |
|---|---|---|
| AADSTS160021 | 対象のユーザー / テナントのセッションが見つからない、または一致しない | MSA でサインインしても、テナント側の「内部ユーザー」と紐付かない |
| AADSTS16000 系 | 要求に対応するアカウント状態が不整合（リソースとユーザーの関連が不正） | UPN 変更やゲスト→メンバー変換で「想定していたユーザー」がいなくなった扱い |
重要なのは、テナント自体は存在しており、ユーザーも消えていないことがほとんどだという点です。
「MSA のままサインインしようとしている」ことが根本原因なので、変換後の「内部 UPN」でサインインし直すのが第一ステップになります。
復旧のために最初にやるべきこと：内部 UPN でサインインする
変換後の UPN を推測する
管理ポータルに入れない状況では、一覧画面を覗いて UPN を確認することができません。とはいえ、外部→メンバー変換のルールは比較的単純なので、多くの場合は推測が可能です。
よくあるパターン：
- 変換前（ゲスト）：
jane_example.com#EXT#@contoso.onmicrosoft.com - 変換後（メンバー）：
[email protected]
つまり、
#EXT#を取り除いて- そのまま @ 以降はテナントのドメイン（
@contoso.onmicrosoft.comなど）
と考えれば OK です。
サインイン画面でのポイント
次に、Azure Portal や Entra 管理センターのサインイン画面で、次の点に注意して操作します。
- サインイン ID として、MSA のメールアドレスではなく、推測した内部 UPN を入力する
- 「アカウントの種類」を問われたら、「個人用」ではなく「職場または学校アカウント」 を選ぶ
| 画面 | 入力・選択内容 | ポイント |
|---|---|---|
| メールアドレス入力 | [email protected] | MSA の [email protected] ではないことに注意 |
| アカウント種別の選択 | 「職場または学校アカウント」 | 「個人アカウント」を選ぶと、MSA へ誘導されてしまう |
| パスワード入力 | 内部ユーザーとして発行された初期パスワード、または変更後のパスワード | ここでパスワード不明な場合は次章の手順へ |
ここで運良くパスワードが分かる／想像がつく場合は、そのままサインインできる可能性があります。一度でもサインインできれば、すぐに MFA やブレークグラス アカウントを整備しておきましょう。
パスワードが分からない場合の選択肢
多くのケースでは、内部ユーザー化された直後の初期パスワードを控えていないため、上述の手順だけでは復旧できません。そのときの選択肢は、次の 3 パターンに分かれます。
| パターン | SSPR 設定 | 他の Global Admin | 現実的な対応 |
|---|---|---|---|
| パターン A | あり | 不問 | SSPR を使って自分でパスワードをリセット |
| パターン B | なし | あり | 他の Global Admin にパスワード リセットを依頼 |
| パターン C | なし | なし（自分だけが管理者） | Microsoft サポートにテナント回復／管理者追加を依頼 |
パターン A：SSPR（セルフサービス パスワード リセット）が使える場合
ユーザーに対して SSPR を有効化し、電話番号や代替メール アドレスなどの認証方法を事前登録していた場合は、比較的簡単に復旧できます。
- サインイン画面で「パスワードを忘れた場合」リンクをクリック
- 内部 UPN（例：
[email protected]）を指定 - 登録済みの電話番号やメールアドレスを使って本人確認
- 新しいパスワードを設定
SSPR でパスワードを再設定できたら、改めてポータルにサインインし、次のことを行います。
- 別の Global Admin アカウントの作成（ブレークグラス用）
- SSPR / MFA の設定状況の見直し
- 外部 → メンバー変換の運用ルールを整備
パターン B：SSPR はないが、他の Global Admin がいる場合
もし同じテナントに自分以外の Global Admin ユーザーが存在するなら、その人に頼むのが最短です。その管理者へ次の作業を依頼します。
- 管理センターから対象ユーザーを検索
- 内部ユーザーとして登録されている UPN を確認
- そのユーザーのパスワードをリセット
- 新しい一時パスワードをあなたに安全な経路で伝える
あなたは受け取った一時パスワードでサインインし、初回サインイン時にパスワードを更新、MFA を設定し直します。
その後、「管理者が 1 人だけ」の状態をやめるように、複数の管理者アカウントを整備してください。
パターン C：自分だけが管理者で完全ロックアウトしている場合
最も厄介なのが、
- SSPR も有効化していない
- 自分以外に Global Admin が存在しない
- その自分がサインインできず、ポータルにもサポートにも入れない
という状態です。この場合は、Microsoft サポートにテナント回復を依頼するしかありません。一般的な流れは次のようになります。
- Microsoft の公式サイトから「サインインに関するサポート」窓口を探す
- テナント名やテナント ID、契約情報（サブスクリプション ID、支払いに使ったメールアドレスなど）を準備
- 状況（外部ゲストをメンバーに変えた結果、唯一の Global Admin がロックアウトした）をできるだけ具体的に説明
- 本人確認に必要な情報を提示し、テナントへのアクセス権復旧（管理者追加やパスワード初期化）を依頼
サポート側の判断やテナント種別（完全な無料試用か、有償契約が紐づいているか）によって対応は変わりますが、正当な管理者であることを証明できれば、何らかの形で復旧してもらえるケースが多いです。
テナントを削除したい場合の考え方
「試用環境なのでテナントごと消してしまいたい」というニーズもありますが、基本的にテナント削除には管理者としてのサインインが必須です。そのため、まずはここまで説明した手順で、何としても一度は管理者としてログインできる状態に戻す必要があります。
テナント削除の一般的な手順
復旧後、テナントを削除したい場合の典型的な流れは次のとおりです。
- 管理者としてサインインできることを確認
- Azure / Microsoft 365 のサブスクリプションを解約、または紐づく支払い情報の整理
- 不要なリソース（VM、ストレージ、アプリ登録、グループ、ユーザーなど）を削除
- カスタム ドメインを使用している場合は、DNS レコードやドメイン確認状態を見直し
- テナント削除の前提条件がすべて満たされたことを確認
- 最後にテナント削除操作を実行
ただし、
- 既に利用しているカスタムドメインを別テナントで再利用したい
- 課金の紐付きだけを切り離したい
といったケースでは、単純に削除すればよいとは限りません。「新しいテナントを作り直す」か「既存テナントを復旧して整理する」かを比較し、影響範囲が小さいほうを選ぶのが現実的です。
| 選択肢 | メリット | デメリット |
|---|---|---|
| テナントを復旧して継続利用 | 既存の設定やドメインを活かせる | 復旧作業や整理に手間がかかる |
| テナントを削除して作り直し | クリーンな状態から再構築できる | カスタムドメインの再利用条件など、制約が出る場合がある |
再発防止：Entra ID 管理者が必ずやっておきたいこと
ブレークグラス（緊急用）管理者アカウントを必ず 2 つ以上用意する
今回のようなロックアウトを防ぐ上で、最も重要なベストプラクティスが「ブレークグラス アカウントを複数用意する」ことです。
- 最低 2 つの Global Admin アカウントを用意する
- 日常運用では使わず、緊急時専用として扱う
- 強力なパスワード＋MFA を設定
- パスワードはオフライン（紙／パスワード マネージャーなど）で安全に保管
- サインイン状況やログを監視し、怪しい使用がないか確認
こうしておけば、1 つの管理者アカウントが壊れても、別の管理者で復旧できます。
外部 → メンバー変換や UPN 変更は「別アカウントでログインした状態」で行う
今回のトラブルの本質は、
- 自分自身のアカウントに対して
- 外部 → メンバー変換や UPN 変更といったサインインに直結する操作を
- そのアカウントでログインしたまま行ってしまった
ことにあります。これを避けるために、次のような運用ルールをおすすめします。
- 自分のアカウントを変更するときは、別の Global Admin でポータルにサインインして作業する
- UPN 変更や外部→メンバー変換の前に、対象アカウント以外の管理者で「管理者権限があること」を確認する
- 変更後、実際に新しい UPN でサインイン確認するまで、そのアカウントは運用に使わない
初期パスワードと復旧手段を必ず記録してから作業する
UPN 変更や外部→メンバー変換は、「パスワード周りの条件が整っていること」が大前提です。作業前に、次のチェックを行いましょう。
| チェック項目 | 確認内容 |
|---|---|
| 初期パスワードの保管 | 内部ユーザーとして作られた際の初期パスワードを安全に控えているか |
| SSPR 登録状況 | 電話番号・代替メールアドレスなど、SSPR に必要な情報が登録されているか |
| MFA 設定 | 復旧に使える MFA 手段（Authenticator アプリ、SMS など）があるか |
| 代替管理者 | 別の Global Admin がサインイン可能な状態か |
これらが整っていれば、仮に何か問題が起きても、復旧の難易度は大きく下がります。
よくある疑問と補足
Q1. すでに MSA 側のアカウントには普通にサインインできている。それでも意味がない？
はい。今回の問題は「MSA にサインインできるかどうか」ではなく、「その MSA とテナント内ユーザーが紐付いているか」が本質です。
外部 → メンバー変換によって #EXT# 付き UPN から内部 UPN に切り替わった時点で、MSA 側の認証とは別物になっています。したがって、MSA のパスワードが分かっていても、それだけではテナントには戻れません。
Q2. Azure Portal だけでなく、Microsoft 365 管理センターにも入れないのは正常？
はい、正常です。
Azure Portal、Microsoft 365 管理センター、Entra 管理センターなどは、いずれも同じテナントの認証基盤（Entra ID）を使っています。どこから入ろうとしても、「テナント内のユーザーとして認識されているか」「パスワードが正しいか」という条件は共通です。
Q3. 外部 → メンバー変換を元に戻せば復旧しますか？
理論上は、別の管理者がサインインして設定を行えれば、外部ユーザーに戻すことも可能です。しかし、
- そもそもその作業を行う別の管理者がいない
- 外部ユーザーに戻しても、元の MSA と完全に同じ状態で復元されるとは限らない
などの理由から、「戻せば必ず復旧する」とは言い切れません。
実運用上は、内部 UPN でのサインインを前提としてパスワードや MFA を整備する方向で考えたほうが安全です。
Q4. どうしてもテナントに戻れない場合、ドメインを新しいテナントで再利用できますか？
カスタム ドメイン（例：example.com）を別テナントで再利用する場合、元のテナントからそのドメインを解除する必要があります。
ロックアウトしたテナントにドメインが残ったままだと、新しいテナントに同じドメインを追加できません。
この場合も、最終的には Microsoft サポートに相談し、状況によってはサポート側でドメインを解放してもらう、テナントの整理を手伝ってもらうなどの対応が必要になります。
まとめ：MSA ではなく「内部 UPN」でのサインインが鍵
最後に、本記事のポイントを整理します。
- 外部ゲスト管理者を「メンバー」に変換すると、UPN から
#EXT#が消え、MSA との紐付けが外れる - その結果、MSA のメールアドレスでサインインしても、テナント内に対応するユーザーが見つからず、AADSTS160021 / 16000 系エラーが発生する
- 復旧の第一歩は、変換後の内部 UPN（
#EXT#なし）を使い、「職場または学校アカウント」としてサインインを試すこと - パスワードが分からない場合は、順に
- SSPR でのパスワード リセット
- 他の Global Admin によるリセット
- Microsoft サポートへのテナント回復依頼
- テナントを削除したい場合も、まずは管理者として再ログインする必要がある
- 再発防止として、
- ブレークグラス Global Admin を最低 2 つ用意
- UPN 変更や外部 → メンバー変換は、別アカウントでログインした状態で実施
- 初期パスワード・SSPR・MFA・連絡先などの復旧手段を事前に整備
要するに、「MSA のアドレスではなく、変換後の内部 UPN でサインインする」ことがスタート地点です。その上で、SSPR や Microsoft サポートを活用すれば、多くのケースでテナントへのアクセスを取り戻すことができます。
これを機に、自身の Entra ID テナントの管理体制を見直し、同様のロックアウト事故を未然に防ぎましょう。
コメント