図6：Azure ADにおける特権アクセスの委譲
Tim：オンプレミスでは。
Randy：そう、観測地点です。可視性が高く、さまざまな場所から開始できます。Ronaldから、いい質問が来ています。 「1つのオブジェクトを複数の管理単位に入れることができますか?」という質問です。つまり、BillyをUSの管理単位に入れ、彼をこの同じユーザアカウントのまま、たとえばその部署の管理単位にも入れることができるか、ということですね。できないと思いますが、やってみたことはありません。やってみてもいいですね。もしそれが可能なら、これまでお話ししてきた多くの仮説は忘れてください。でも考えてもみなかったのです。はっきり言いませんでしたが、1つの場所にしか入れられないと思いこんでいました。たしかに検証の必要がありますね。
ではやってみましょう。まずは、グループを作成します。Azure ADに行ってグループを作成するのです。これはセキュリティグループです。ロールを割り当てるためには、こうする必要があります。名前は米国ヘルプデスクです。私がしたかったのは、Azure ADのロールに対して、これを有効にすることです。Office Microsoft 365のグループにすることもできます。ともかく、このままにしておきましょう。そうすればこのグループが作成できます。この作業は嫌いなんです。
待ち時間が長いので。さあ、グループができましたね。米国ヘルプデスクという名前です。
Tim：でもこれをディレクトリに拡散しなければならないのでは? ああ、できましたね。
Randy：はい、グループができました。メンバーはまだいません。Barryをメンバーにしましょう。少し待たねばなりません。
Tim：私が言いたかったのは、ここで再読み込みをクリックするにも、管理単位やグループを作成しようとしたりするにも、グループを定義する時にそこでロールを作成するオプションがあるということです。それに従ってロールを作成することもできるし、既存のロールを使うこともできるのです。
Randy：そう、両方ともできます。それに、ロールの割り当てなども同時にすることもできます。でも、本当に理解していただきたいのは、お気づきと思いますが、オブジェクトとそれぞれの関連性です。
Tim：そうですね。
Randy：これで米国ヘルプデスクというグループができ、Barryという人が入っています。彼にはもう、何か行なう権限があるのでしょうか? まだです。ところで言い忘れましたが、グループを入れ子にすることもできます。グループの入れ子構造は、Azure ADで強調しなければならないポイントです。オンプレミスのADと似ていますね。グループの中にメンバーのグループを入れることができます。そうするメリットはたしかにありますが、管理単位にはその機能、入れ子構造はありません。
Markの質問です。BarryはあらかじめAzure ADのユーザでなければなりませんか? はい。Barryにはすでにここでのアカウントがあります。それは必須です。次のステップは、管理単位を作成することです。さあ、できました。次にすべきなのは……
Tim：選ぶことです。
Randy：そう。グループの下にある管理単位は何か? 一連のパーミッションでなければなりません。
Tim：はい。
Randy：そのグループがメンバーになっている管理単位になるのですね。
Tim：はい。
Randy：わかりました。
これはやめましょう。意図していたのと違います。ディレクトリまで、Azure ADの根本まで戻り、管理単位に行きます。ここに新しい管理単位を作成します。こちらは米国のエンドユーザです。もう少し具体的にしてみましょう。ここではまだ、ロールなどを割り当てたくありません。これで米国のエンドユーザができました。ここに米国で作業をしている人をすべて追加することができます。たとえば、Brendanは米国で作業しているとします。Randyも米国で作業しています。だから二人ともここに加えましょう。
だんだん完成に近づいてきましたよ。最後にしなければならないのは、この米国ヘルプデスクというグループを、管理単位である米国エンドユーザとリンクさせることです。やってみましょう。これにはいくつか方法があります。管理単位のロールと管理者のところへ行き、パスワードリセットの権限を持つ米国ヘルプデスクを追加することもできるし、グループに行って割り当てられたロールを見ることもできます。どちらのやり方にしましょうか? 結果は同じで、それが大事なのです。私はWindowsのオンプレミス環境で過ごしてきたので、オブジェクトに行って、そのオブジェクトへのアクセス権を持つ人を決めるほうがいいのですが、あなたはどうでしょう。
Tim：そうですね。我々のように比較的年長で、Active Directoryに慣れた人間にはそのほうが一般的ですね。
Randy：はい。それにUnixにも、ですね。ファイルにパーミッションがある。
Tim：そうです。
Randy：では、米国エンドユーザ、そして、ロールと管理者、そしてパスワード管理者に移りましょう。ここで米国ヘルプデスクを追加します。米国ヘルプデスクは、米国エンドユーザに対するパスワード管理者のロールを持ちます。ここにあるUIだけでは、何が起こっているか見えにくいですね。たとえば、米国エンドユーザに対する権限を持っているのは誰か? では、ロールと管理者、それにパスワード管理者へ移ります。
ここでは、それが誰なのかわかりません。中へ入って割り当てを見なければ。すると、米国ヘルプデスクがこれを持っていて、米国ヘルプデスクがグループであることがわかります。ここをクリックすると米国ヘルプデスクに行ってメンバーを見ることができます。Barryがメンバーになっていますね。ここから反対方向へ行くこともできます。米国ヘルプデスクのほうへ行ってみましょう。ここには何の権限が与えられているでしょう? ああ、パスワードリセットの権限です。では、米国エンドユーザに対する範囲はどうでしょう? これは管理単位です。このように、観測地点として双方向から見ることができます。ではアクセスについて見てみましょう。何でしょう?
Tim：先へ進む前に、Jenniferからとても興味深いコメントが来ています。Office 365からこれを見ると、オンプレミスADに戻ってフェデレーションとAzure ADの同期を利用することができるというのです。AADを立ち上げて、この機能をいくつか閉じてもいいでしょうか? 誰かがAzure ADに入ってきて、そこでグループやロールなどを作成し、それがオンプレミスのADから見えないというのは、彼女には不本意でしょうから。
Randy：もちろん、それはわかります。それに、あなたのグローバルのエンタイトルメントを誰に持たせるかを制御するというだけのことですから。もう1つお見せしたいものがあります。ユーザや保管者、管理者の視点からはどう見えるのかということです。Barryに戻りましょう。Barryに割り当てられたロールは何ですか? 面白いですね。これは、オンプレミスのADでは決してできないことです。Barryがパスワード管理者の権限を持っていることがわかりますが、私は彼に直接その権限を与えていません。これが、割り当てパスという概念です。米国ヘルプデスクのメンバーだという事実によって、彼は米国エンドユーザに対するパスワードリセットの権限を持つことになるのです。これは、[crosstalk 00:50:35]ではずっと奥深くまでクリックを繰り返さなければ見られない現象です。
Tim：オンプレミスのADでは、ということですね。
Randy：ではここで思い出してください。私たちはAzure ADについてだけお話ししています。Azureには他の機能もあり、あなたにはAzureのオブジェクトもあります。そうしたAzureオブジェクトの中には、独自にセキュリティ機能を持つものもあるのです。Azure SQLデータベースは、リソースグループなどに入れることのできるオブジェクトです。でも大事なことは、Azureデータベースのレベルで、Azure ADとは全く何の関係もないユーザアカウントを持てるのです。これはSQLユーザの仮想アカウントで、Azure SQLの中のデータベースに管理者権限を持つこともあります。でもそれは、全く異次元の話です。