Azure AD B2Bを見てみよう Part2

皆さんこんにちは。国井です。
前回はAzure AD B2Bでゲストユーザーの作り方について紹介しました。
このとき、ゲストユーザーとして作成するユーザーは元のユーザーがいる前提であるかのように語っていましたが、実は元のユーザーがいなくても作れます。

では、元のユーザーがいない状態でゲストユーザーを作ったら、どうなってしまうのでしょうか?今回は、パターン別にゲストユーザーを作成したときの影響についてみてみます。

既にAzure ADテナント/ユーザーが作られている場合

ゲストユーザーを登録するAzure ADテナントの相手となるAzure ADテナント(画面下で言うところのパートナーテナント)が既に作られており、Azure ADユーザーも作られている場合、ゲストユーザーを作成すると、前回紹介させていただいたような(単純に)ゲストユーザーを登録する作業が処理されます。

image

ゲストユーザーとして登録されたユーザーは送られてきたメールのリンクをクリックするか、アクセス許可が割り当てられているクラウドサービス(アプリ)にアクセスし、初回アクセス時にOAuth2.0の同意画面で同意することで、

image

ゲストユーザーが利用開始できるようになるのと同時にアプリへのアクセスも開始できるようになります。これまでの投稿でも解説してきたような普通の動きです。

マイクロソフトアカウントを登録する場合

ゲストユーザーとして登録するユーザーがマイクロソフトアカウントの場合、他のテナントのAzure ADユーザーと同じように登録が可能です。

image

ゲストユーザーとして登録されたユーザー(マイクロソフトアカウント)は送られてきたメールのリンクをクリックするか、アクセス許可が割り当てられているクラウドサービス(アプリ)にアクセスし、初回アクセス時にOAuth2.0の同意画面で同意することで、ゲストユーザーの登録が完了します。最初のパターンと変わることはなにひとつありません。

Azure ADユーザーがまだ存在しない場合

既にAzure ADテナントはあるが、Azure ADユーザーがまだ存在しない場合は少しやっかいです。ゲストユーザーを登録し、メールのリンクをクリックすると、アクセス許可のあるクラウドサービス(アプリ)にアクセスできるようになるのですが、同時にゲストユーザーを登録したAzure ADテナントの相手となるテナント(画面下のパートナーテナント)にAzure ADユーザーが自動的に作られます。

image

Azure ADユーザーが勝手に作られると言っても、Azure ADユーザーのパスワードとかどうなるの?って思うかもしれません。そこは次のような仕組みでパスワードが設定され、ユーザーが作成されます。

ゲストユーザーとして登録されたユーザー(メールアドレス)は、メールのリンクをクリックしたタイミングで、Azure ADユーザーのパスワード設定画面が下のように出てくるのです。

image

ここでパスワードを設定すると、そのパスワードがAzure ADユーザーのパスワードとして使われることになり、ユーザーが勝手に作成されます。
そのため、理解して使わないと、勝手にユーザーが増える事態になりますから注意が必要です。

まだAzure ADテナント/ユーザーが存在しない場合

Azure ADユーザーどころか、Azure ADテナントもまだ存在しない状態でゲストユーザーを作成すると、メールのリンクをクリックしたタイミングでAzure ADテナントとAzure ADユーザーを勝手に作ります。

image

画面ショットがないので、わかりやすくないかもしれないですが、メールのリンクをクリックすると、そのユーザーのパスワード設定画面と同時に、国または地域を選択する画面が表示されます。この、国または地域の選択画面はAzure ADテナントの作成に必要な情報を聞いてきているんですね。ですので、これらの情報の入力が完了すると、Azure ADテナントとユーザーを作成するための情報が整い、すべてが勝手に作られてしまうのです。

勝手に作られたAzure ADテナントは、どう管理する?

勝手に作られたAzure ADテナントは管理者がいない状態のテナントとなります。管理者がいない状態から、新しく管理者を定義するときは勝手に作られたAzure ADテナントのユーザーでAzure AD PowerShellにサインインし、Azure ADテナントに登録されたドメインの承認作業を行います。
最初に以下を実行し、(1行で実行してください)

Get-MsolDomainVerificationDns -DomainName <ドメイン名> -Mode DnsTxtRecord

TXTレコードを取得して、DNSサーバーにTXTレコードを登録したら、

Confirm-MsolEmailVerifiedDomain -DomainName <ドメイン名>

と実行することで、カスタムドメインの本登録が完了すると同時にこの操作を行ったユーザーがAzure ADテナントの全体管理者に昇格します。

これで勝手に作られたAzure ADテナントを管理できるようになるのですが、勝手に作られたAzure ADテナントの勝手に作られたAzure ADユーザーが管理者にしたいユーザーとは限らないですよね。これがまたこの運用の大変なところでもあるのです。

次回はどんなタイミングでAzure ADテナントやユーザーが作られるのか、見ていく予定です。

スポンサーリンク







  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください