Microsoft 365 のライセンスを Apps for business から Business Standard に変更しようとしたのに、なぜか 403 エラーで失敗する。
しかも管理者権限の問題には見えず、何度やっても更新できない。
今回は、SSO 経由のライセンス変更で実際に詰まった事例と、最終的に解決できた手順をまとめます。
Microsoft 365 のライセンスを、Microsoft 365 管理センターではなく SSO 側のプロビジョニング機能で管理している環境で、あるユーザーのライセンスを Microsoft 365 Apps for business から Microsoft 365 Business Standard に変更しようとしたところ、何度試してもエラーになりました。
表示されたエラーは次のとおりです。
Forbidden (403) Insufficient privileges to complete the operation
最初は「権限不足かな？」と思ったのですが、最終的には Teams Exploratory の影響でライセンス状態が競合していた可能性が高い、という結論になりました。
今回は、実際に解決できた手順を、同じように詰まった方向けにまとめます。
SSO 経由で Microsoft 365 のライセンス管理をしている環境なら、似た状況の切り分けに使えるかもしれません。
[ 目次 ]
発生した状況
今回の前提は次のとおりです。
Microsoft 365 のライセンス管理は、Microsoft 365 管理センターで直接行わず、SSO 側のプロビジョニング機能で実施対象ユーザーは、これまで Microsoft 365 Apps for business を利用。
このユーザーを Microsoft 365 Business Standard に変更したい
しかし、SSO 側で何度更新しても失敗する
エラー内容は以下でした。
Forbidden (403) Insufficient privileges to complete the operation
一般論として、Microsoft Graph でユーザーのライセンス追加・削除を行う処理は、必要な権限やロールが不足していると 403 エラーになることがあります。
Microsoft の公式ドキュメントでも、ライセンス割り当てには対応する権限や Microsoft Entra ロールが必要とされています。
ただ、今回は 他ユーザーでは問題なく更新できるのに、特定のユーザーだけ失敗する 状況でした。
そのため、単純な管理者権限不足ではなく、そのユーザー固有のライセンス状態を疑いました。
原因として怪しかったもの
調査の中で怪しかったのが、Teams Exploratoryです。
Microsoft の公式情報によると、Teams Exploratory は Teams の有効なライセンスを持っていないユーザーが自己サービスで開始できる試用ライセンスです。
つまり、Apps for business のように Teams を含まないライセンスを使っているユーザーが Teams を使い始めた場合、裏側で Teams Exploratory が関与している可能性があります。
今回の対象ユーザーも、Microsoft 365 管理センターの該当ユーザー画面だけを見る限り、すぐには違和感が分かりませんでした。
ただ、状況を整理すると次のように読めました。
ユーザーには Apps for business が付与されていた
Apps for business には Teams が含まれていない
そのため、ユーザーが Teams を利用する中で Teams Exploratory（自己サービス試用版） が割り当てられていた可能性がある。
この試用系ライセンスの状態が残っていたことで、Business Standard への更新時に競合し、結果として 403 エラーになった可能性が高い
正直、最初は「403 だから権限不足だろう」と考えていました。
ただ、表示されたエラーだけで真因を決めつけたのは、少々勇み足でした。
実際に解決した手段
ここからは、実際に解決できた手順です。
1. Microsoft 365 管理センター側で Teams Exploratory の状態を整理する
まず、Microsoft 365 管理センター側で、対象ユーザーに関係している Teams Exploratory の状態を整理しました。
今回の環境では、Teams Exploratory をいったん Business Standard への昇格予定として更新するような流れを取りました。
ここはテナントの状態や表示によって多少異なるかもしれませんが、考え方としては、「試用系ライセンスの状態をいったん整理し、有償ライセンスへ移行しやすい状態に寄せる」というイメージです。
2. その後、Business Standard を解除して一時的にライセンスなし状態にする
次に、Business Standard のライセンスを一度解除し、対象ユーザーを一時的にライセンスなし状態にしました。
この操作は少し不安になるかもしれませんが、今回のポイントは中途半端に残っているライセンス状態をいったんクリアにすることにありました。
SSO側からの再割り当てを成功させるには、先に Microsoft 365 側の状態をきれいにしておく必要があったようです。
3. SSO側のプロビジョニングで Business Standard を再割り当てする
その後、いつもの運用どおり SSO 側のプロビジョニング機能から Business Standard を再度割り当てたところ、今度は正常に更新されました。
結果として、
変更前：Apps for business
変更後：Business Standard
への切り替えが、ようやく問題なく完了しました。
なぜ 403 エラーなのに「単純な権限不足」ではなかったのか
今回やや厄介だったのは、エラーメッセージが
Insufficient privileges to complete the operation
だったことです。
この文言だけを見ると、どうしても
「管理者権限が足りないのでは？」
「API の権限設定が不足しているのでは？」
と考えがちです。
もちろん、それ自体は間違いではありません。Microsoft Graph のライセンス割り当て処理は、必要な権限やロールが足りなければ 403 になります。
ただ、今回のように
他ユーザーは問題なく更新できる
特定ユーザーだけ失敗する
Teams を含まないプランから、Teams を含むプランに変更しようとしている
しかも SSO 側の自動処理で付け替えている
という条件がそろう場合は、権限不足そのものよりも、ライセンス状態の競合を疑ったほうが早いと感じました。
再発防止として考えたいこと
今回のような事象を防ぐには、運用面でも少し見直しの余地があります。
特に、Teams を含まないライセンスを使っているユーザーが、自己サービスで試用ライセンスを持ってしまう運用があると、あとで管理が複雑になりやすいです。
Microsoft も、Teams Exploratory のような自己サービストライアルについて、管理者側で確認・制御する考え方を案内しています。
運用担当の立場で考えるなら、少なくとも次の3点はルール化しておくとよさそうです。
Teams を含まないプラン利用者の扱いをどうするか
自己サービストライアルを許可するかどうか
ライセンス変更時に、事前確認する項目をどう定めるか
【PR】あわせて見ておきたい実務本・業務効率化アイテム
Microsoft 365 や Teams 周りのトラブルは、一度ハマると原因特定に時間がかかることがあります。
私自身、こうした切り分けをする中で、関連書籍で仕様を確認したり、日々の業務環境を整えたりしておくことは、地味に効くと感じています。
もし普段から Microsoft 365 の運用や Teams 管理を担当しているなら、次のようなものも見ておくと役立つかもしれません。
Microsoft 365 / Teams 関連の実務書
Microsoft 365 や Teams の仕様変更は細かく、トラブル時に「知っているかどうか」で切り分け速度がかなり変わります。
まずは、実務寄りの書籍を1冊持っておくと安心です。
情シス・社内SE向けの運用本
アカウント管理、ライセンス管理、手順化、問い合わせ対応まで含めて考えるなら、情シス・社内SE向けの運用本も相性がいいです。
他のSEの方も独自の視点や技術情報を公開されています。
また、システム構築、業務改善、office365の活用事例もご紹介されているサイトもあｒますので皆さんも参考にされてはいかがでしょうか↓
にほんブログ村
