Azure AD へのアプリケーション登録を禁止すると AAD が乱立してしまうという話

この記事の内容

  • Azure AD（Azure Active Directory）へのアプリケーション登録を禁止する設定が、逆に AAD の乱立を招くことを解説します
  • Windows Admin Center を使った Azure 連携の実例を通じて、禁止設定がどのような問題を引き起こすかを示します
  • 「良かれと思った設定」が組織の管理を困難にする構造的な問題を説明します
  • 管理者が取るべき正しいアプローチについて提言します

はじめに

本記事は「Microsoft のクラウドサービスを使うならこれだけは知っておかないとまずいこと」シリーズの第5弾です。これまでの回では、Azure AD テナントはなるべく一つに集約し、その状態を保つことの重要性をお伝えしてきました。

今回は、良かれと思って行った設定が、むしろ Azure AD を乱立させてしまうという、現場で非常によく見られる問題について取り上げます。

Windows Admin Center での Azure 連携を試してみる

Windows Admin Center は Microsoft が提供する Windows の管理ツールです。Azure AD 認証と統合することで、さまざまな ID 管理・強化が実現できます。Azure サービスとのハイブリッド連携を行うのは自然な流れです。

Windows Admin Center から Azure サービスを使用する際には、次のような手順が必要になります。

  1. Azure グローバル（Azure クラウド）を選択する
  2. 画面に表示されたコードをコピーし、デバイスログイン画面に入力する
  3. 組織のアカウントでサインインする
  4. Azure Active Directory のテナント ID を選択する
  5. Azure AD 上にアプリケーションを新規作成するか、既存のものを使用するかを選択する

この流れで「新規作成」を選択すると、一般ユーザーの場合に次のようなエラーが表示されることがあります。

アプリケーションはAzureActiveDirectoryに登録できませんでした

なぜエラーになるのか？

このエラーの原因は、Azure AD の管理画面にあります。

管理者が Azure Active Directory の管理画面を開き、「ユーザー設定」 を確認すると、「アプリの登録」という項目があります。ここが 「いいえ」 に設定されていると、一般ユーザーは Azure AD へのアプリケーション登録ができません。

この設定を禁止していると、Windows Admin Center の Azure 連携が動作しないだけでなく、ハイブリッド機能全般が使えない状態になってしまいます。

なぜ管理者は登録を禁止したくなるのか？

Azure AD へのアプリケーション登録を禁止したくなる理由は、心理的にとても理解できます。

オンプレミスの Active Directory では、一般ユーザーがディレクトリ上にオブジェクトを作成するという概念がほとんどありませんでした。ところがクラウドの世界では、Azure AD へのアプリケーション登録はカジュアルに行われる実装です。

管理者としては「よくわからないものが勝手に増えていく」という不安から、とりあえず禁止という判断に至りがちです。アプリの登録画面にはさまざまなアプリケーションが並んでおり、一般ユーザーが自由に追加できる状態に不安を感じるのは自然なことです。

しかしこの「良かれと思った設定」が、より深刻な問題を引き起こします。

禁止されると、ユーザーはどうするか？

Azure AD へのアプリケーション登録が禁止されていても、ユーザーはやりたいことをやらなければなりません。そのとき、彼らはどうするでしょうか？

答えは新しい Azure AD テナントを自分で作ることです。

Azure ポータルから「リソースの作成」を選択し、「Active Directory」と検索すると、Azure AD テナントを新規作成できます。この操作は特別な権限がなくても、無料で行えます。

Azureポータル→リソースの作成→"ActiveDirectory"で検索→新規作成

自分のサブスクリプションの所有者であれば、新しく作った Azure AD テナントにサブスクリプションを切り替えて検証を進めることができます。

結果として何が起きるか？

ここに問題の本質があります。

  • Azure AD へのアプリケーション登録は禁止されている
  • しかしユーザーは Azure を使って検証や開発をしなければならない
  • やむを得ず、自分で新しい Azure AD テナントを作成する
  • そのテナントで作業を進める

エンジニアが 100 人いれば、こうして 100 個、200 個、300 個と Azure AD テナントが乱立していきます。

管理しやすくしようとした設定が、まったく管理できない状況を作り出してしまう。 これが最大の皮肉です。

同様のことは Teams のゲストユーザー招待禁止でも起きます。招待を禁止されれば、ユーザーは別の Azure AD テナントを作り、そこで Teams を立ち上げ、ゲストを招待します。禁止しても「やらなければならない」状況があれば、必ず抜け道が使われます。

管理者が本来すべきこと

管理者の本来の役割は、ユーザーが一番使いやすい環境を公式に用意することです。

使いやすい公式の場所があれば、みんなそこを使います。そうすれば情報やリソースが分散せず、シャドー IT も生まれません。

アプリケーション登録への対応例としては、以下のようなアプローチが考えられます。

  • セルフサービスでの作成を許可する（ユーザーが自由に登録できるようにする）
  • 申請フローを整備する（「申請すれば作れます」という正式なパスを設ける）

どちらにしても、「作るパスを必ず用意する」 ことが重要です。禁止したまま放置し、裏でどんどんテナントが増えているのを見て見ぬふりをするのは最悪の状態です。

管理者へのチェックリスト

以下の点を今すぐ確認してみてください。

  • Azure AD のユーザー設定で「アプリの登録」が「いいえ」になっていないか？
  • 「できるべきことができない」環境になっていないか？
  • 禁止設定が抜け道を使わせる結果になっていないか？
  • アプリケーション登録の公式なフロー（セルフサービスまたは申請）が整備されているか？

まとめ

Azure AD へのアプリケーション登録を禁止する設定は、管理者が「Azure AD をクリーンに保ちたい」という善意から行われることがほとんどです。しかしその結果、ユーザーは自分で新しい Azure AD テナントを作り、組織全体で管理不能なテナントの乱立を招いてしまいます。

「禁止する」ことが必ずしも安全につながるわけではありません。ユーザーが正しい方法で目的を達成できる環境を整えることが、管理者の本来の仕事です。アプリケーション登録の申請フロー整備やセルフサービスの許可など、実態に即した運用を検討してみてください。