個人アカウントと組織アカウント

Azure Active Directory
スポンサーリンク

マイクロソフトのクラウドサービスを利用しようとしたり、クラウドプラットフォーム上でIDを作成、管理しようとしたときにまず1番最初に混乱するのが「個人アカウント」と「組織アカウント」の違いだと思います。両方の種類のIDが使えるサービス、片方のIDしか使えないサービス、両方のIDが使えるんだけど、実は領域が別れているサービスなど、多種多様な状況です。私自身かなり長期間に渡って苦しめられてきたというのが正直な所です。

少々技術的に細かい話にもなってしまいますが、しっかりと説明してみたいと思います。

なお、私個人のおすすめは「使える所は全て組織アカウントで統一する」です。

スポンサーリンク

歴史的経緯

まず最初にこの話には歴史的経緯があるのだということを認識しておくのがおすすめです。そして、特に「Azure」関連で度々の仕様変更があり、それが複雑さに拍車をかけています。具体的には当初、「個人アカウント」でしかAzureの管理ができない時代がありました。

ですが、その後、Office 365の普及=Azure ADの普及=「組織アカウント」の普及に伴って、Azureの管理がどんどん「個人アカウント」ではなく、「組織アカウント」で行うべきものに変化してきました。

この影響を受けて個人アカウントと組織アカウントの混在や、役割の変化、ドキュメントによって言っていることが違う…等の混乱を生むことになった…というのが私の理解です。

ですので、過去のドキュメントを見る時にはこのあたりも注意してもらうのが良いと思います。

注意:このあたり人によっては全く違う見解、意見を持っているかとは思います。石を投げないで下さい。

個人アカウント=マイクロソフトアカウント
組織アカウント=Azure Active Directoryのアカウント=Office 365のアカウント

まず一番最初に理解すべきことは、個人アカウントが「マイクロソフトアカウント」であり、組織アカウントは「Azure Active Directoryのアカウント(=Office 365のアカウント)」であるということです。それぞれは「誰が管理者なのか」という点で明確に大きな違いがあります。

「個人アカウント=マイクロソフトアカウント」は個人が勝手に作成できる

マイクロソフトアカウントは以下のURLから作成できるアカウントです。

無料で作成できるにもかかわらずメールアドレスを取得し、outllok.comでメールの送受信をおこなったり、OneDriveでオンラインストレージを保有し、PCとも同期ができてしまうような非常にお得なアカウントです。

新規にxxx@outlook.com, xxx@outlook.jp, xxx@hotmail.com等のメールアドレスを取得してアカウントを作成することも、すでに自分が利用しているメールアドレスをつかってアカウントを作成することもできます。

マイクロソフトアカウントはWindows 10とも統合されており、マイクロソフトアカウントでWindows 10にログインすることもできます。他にも様々なマイクロソフトのクラウドサービスにて使用することができるアカウントになります。

無料で作成できるアカウントにもかかわらずメールもオンラインストレージもついてくるなんて本当にいい時代になりましたね。(マイクロソフトアカウントに限らずの話ですが)

このマイクロソフトアカウントの最大のポイントは個人が勝手に作成できる個人利用のためのアカウントという所です。単純にインターネット接続とブラウザだけあれば簡単にマイクロソフトアカウントが作成できます。誰かに承認を得る必要もなければ、組織でコンセンサスを取る必要もありません。作成したければいくらでも勝手に作成できます。

マイクロソフトアカウントはあくまでも個人が自分で作成したアカウントであるという位置づけです。ですから、マイクロソフトアカウントに登録してある情報を編集しようと思っても、それができるのはあくまでも本人だけです。だれか管理者に頼んでパスワードをリセットしてもらったり、メールアドレスを追加してもらったり…というようなことはありませんし、できません。

※組織の管理者によって従業員ひとりひとりのマイクロソフトアカウントを作成して配布する…というような運用をされているところがあってもおかしくありません。ですが、このような運用は本来意図されているものではなく、やめたほうが良いでしょう。(規約をよく読むと禁止されている事かもしれません。)

「組織アカウント=Azure Active Directoryのアカウント=Office 365のアカウント」は管理者が作成する

組織アカウントは別の呼び方としては「学校および職場のアカウント」と呼ばれます。つまり学校や職場等の組織において作成、利用されるアカウントです。このアカウントは組織的に作成、利用されますので、勝手に個人が作成することはできません。きちんと管理者がネーミングルールや各種セキュリティポリシーを設定しつつ、入学、入社等のタイミングで作成し、利用者に払い出す形となるのが通常です。

これはまさに、オンプレミス時代のActive Directoryのアカウントを想像してもらえれば良いと思います。ドメインの管理者が全体に対して権限を持ち、管理をしていました。それのクラウド時代のクラウド上のアカウントの呼び方が「組織アカウント」なのです。

この「組織アカウント」は実体としてはAzure Active Directory上のアカウントになります。

あえてそういう呼び方はしませんが、オンプレミスのActive Directory上のユーザーアカウントも分類するなら個人アカウントではなく、組織アカウントと考えられますね。

こちらも最大のポイントは「管理者が作成、管理するものであり、個人では勝手に作成できない組織のためのアカウント」という所です。

組織アカウントはマイクロソフトのクラウドサービスを組織で利用する時に必要となる

組織アカウントはマイクロソフトのクラウドサービスを組織で利用する時に必要となります。実はマイクロソフトのクラウドサービスの出始めのころは「組織アカウント」という呼び方も「Azure Active Directory」もほぼ説明されていませんでした。

Office 365の前身のBPOSというクラウドサービスのときには単にBPOSに対してIDを作成する、IDを同期するという概念だったと記憶しています。(※昔のことなので記憶違いかもしれません。)

それこそ、マイクロソフトの提供するクラウドサービスにしても、サービス毎にIDシステムが別々に管理されており、それらが裏で同期するような実装の時代もありました。(※これは色々と苦労しながら確認、検証した記憶があるので間違いありません。部分的には今でもそうかもしれません。)

ですが、IDのシステムが全てのクラウドサービスで一環していなければ様々な面で不都合が出てきます。例えば、ユーザーを作成した直後にAサービスではそのユーザーがすぐ使えるけれども、Bサービスではしばらく待たないと使えない…、グループのメンバーに入れたのにそれがすぐに反映されるサービスと反映サービスがある…となると使いづらいですよね。

ある時から明示的に「Azure Active Directoryに組織アカウントがあり、全てのマイクロソフトのクラウドサービスはAzure Active Directoryと紐付いて動作する」というように大方針が固まり、実装されだしました。(※胡田の認識です。)

実はこの方針への転換は道半ばです。Office 365、Azure、Dynamics 365等の企業向けのクラウドサービスに関してはそれを契約し、利用開始すると自動的にAzure Active Directoryを利用する形態になりますが、実はまだパートナー向けの各種サービスに関しては個別に存在していて、個人アカウント=マイクロソフトアカウントで認証されるシステムも残っていたりします。パートナー向けシステムに関しては今まさに組織アカウント=Azure Active Directoryのアカウントで利用可能なように日々進化、変化しています。(※2018年4月時点のお話です)

マイクロソフトアカウントで使えるメールアドレス

さて、ここまでで「マイクロソフトアカウントは個人のアカウントであり個人が作る」「Azure Active Directoryのアカウントは組織のアカウントであり管理者が作成する」ということで整理できたと思います。

ですが、この流れに一つ矛盾してしまうパターンがあります。それは以下のパターンです。

  • 個人アカウントであるマイクロソフトアカウントを組織で付与された電子メールアドレスを使用して作成する

個人のアカウントであるマイクロソフトアカウントなのに、組織で付与された電子メールアドレスを使って作成してしまうと、個人のものなのか、組織のものなのか位置づけが分かりづらくなってしまいます。

そしてまさにこのパターンにおいて様々な混乱が引き起こされることになります。

その中でも典型的に混乱しがちなパターンは「個人アカウントと組織アカウントの両方に同じ電子メールアドレスが使われている」という状況です。

何を隠そう、私自身もこのパターンのユーザーです。会社で利用しているmasahiko.ebisuda@jbs.comというアドレスは組織アカウントとしてExchange Onlineをメールシステムとして利用していますが、マイクロソフトアカウントとしてもmasahiko.ebisuda@jbs.comを取得してあります。

では、この状態で例えばAzureのポータルに「masahiko.ebisuda@jbs.com」としてアクセスすると、どちらのユーザーとしてシステムを利用することになるでしょうか?「masahiko.ebisuda@jbs.com」に対してアクセス権を設定したらマイクロソフトアカウントと、組織アカウントのどちらに権限を付与したことになるでしょうか?

このあたり、一筋縄ではいかないことがちょっと考えてもらっただけでもわかると思います。

この混乱の時期が結構長く続きましたが、現状はかなり仕様が変更されて改善されてきています。

まず1つはサインインする場面できちんと選択肢が表示され明示的に選択できるようになったことです。

このように、組織アカウントと個人アカウントという概念を知っていれば適切に選択できるようなGUIになりました。(以前はもっとずっと分かりづらかったんです!)

 

もう1つは、「個人アカウントであるマイクロソフトアカウントを組織で付与された電子メールアドレスを使用して作成する」ということができないようになりました。このことは下記のブログエントリで説明されています。

この対応は相当の混乱や内容をよく理解できない人の誤解を多く招いたという事実はありますが、少なくとも現状新しくアカウントが作成できなくなり、分かりづらい状態にはなりづらくなっています。

ただし、完全には改善しきれていない状況があるのもまた事実です。以下、まだ混乱する状況が発生するパターンや条件を見ていきたいと思います。

「職場のメールアドレス」というのはどうやって判定しているのか?

Microsoftのブログエントリに下記の文章があります。

本日より、Azure AD で構成済みの電子メール ドメインでは、職場または学校のメール アドレスを使用して Microsoft アカウントを新規作成することが禁止されました。

「職場または学校のメールアドレスである」ということはどうやって判定しているのでしょうか?ちょっと想像しても、結構難しそうだと思うと思います。

これは現状は「Azure Active Directoryに登録されている(メール)ドメインであれば職場または学校のメールアドレスと判断する」というロジックになっています。

ですので、「すでに学校、会社がOffice365を使っていて、ドメインも登録されていて、Exchange Onlineでは@aaa.bbb.cccというメールドメインを使っている」という状況では@aaa.bbb.cccというドメインのメールではマイクロソフトアカウントを取得することはできません。

ですが、「Azure Active Directory、Office 365、使っていない」という組織であればそのメールドメインでもってマイクロソフトアカウントを作成することは今でも可能なのです。そのうえで、その組織がOffice 365を使い始めると…、やはり個人アカウントと組織アカウントでのメールアドレスの重複は発生してしまうことになります。

意図せず組織アカウントが生成されるパターンがある

さらに混乱に拍車をかけるのは、意図せずに組織アカウントが生成されるパターンがあるという事実です。有名なところでは、「組織外からAzure Information Protectionで暗号化されたメールを受け取ってそれを開いた」という状況です。

Office 365を使っていなくても、Azure Active Directoryを使っていなくても、暗号化されたメールを受け取れる、表示できるのは素晴らしいことなのですが、Azure Information ProtectionはAzure Active Directory上にIDがありそれをキーにして動作する動きをします。Azure Active Directory上にアカウントがないと動作できないので…、それがない状況であれば自動的に生成する(Azure Active Directory自体も、その中に暗号化されたメールを開こうとしたIDも)という動きをします。

なので、なにも意図せずに組織アカウントが作成されているケースというものがあります。そうすると、個人アカウントと組織アカウントの両方が存在するパターンができてしまい混乱の元になってしまいます。

どの種類のユーザーを利用できるのか?

個人アカウントと組織アカウントの2種類のアカウントがあり、意図せず両方の種類のアカウントが作成されてしまうパターンがあることも見てきました。ではどのサービスではどちらの種類のユーザーを利用できるのでしょうか?

これがやっかいなことに、完全に「システムによって異なる」というのが現状です。例えば有名な所だと、Azureは当初個人アカウント(マイクロソフトアカウント)のみしか利用できました。次に組織アカウントも利用可能となりました。そして、ポータルが新ポータルに切り替わったタイミングでマイクロソフトアカウントもまだ使えるのですが、組織アカウントの方が優先して使われる状態になりました。

PowerBIは組織アカウントでしか使えません。

OneDriveは個人アカウントには個人アカウント用の領域が、組織アカウントには組織アカウント用の領域があります。

SharePoint Onlineは組織アカウントとマイクロソフトアカウントの両方が利用できます。自分がどちらで権限を割り振られているのか理解しておかないとかなり混乱しやすいです。

Azure Enterprise Portalには認証レベルの切り替えという機能すらあります。

このあたりのまちまちさがさらに混乱を深めている気がします…。

Azureは特に特殊(規定のディレクトリの概念)

そして1番注意しなければいけないのはAzureです。

Azureには「サブスクリプション」という概念がありますが、そのサブスクリプションには「規定のディレクトリ」という概念があります。さらに、規定のディレクトリは「変更」できます。

Azureへの権限付与は基本的に「サブスクリプション」単位で行われ、「サブスクリプション」と紐づくAzure Active Directoryの中のユーザーのみが権限設定に使える仕様になっています。これはつまり組織アカウントですね。

しかし、組織アカウントではあるのですが、それがOffice 365で使っているいつものユーザーを指すのかというと「必ずしもそういうわけではない」です。

Azure Active Directoryはいくつでも自由に作成できますし、そのどのAzure Active Directoryに紐づくのかは管理者がコントロールできるのです。

そして、組織アカウントだけではなくて、個人アカウントでも権限設定が行えるという事実があります。むしろ普通に契約をして普通に手続きを進めると個人アカウントで権限設定がなされている状態となります。

「招待(権限付与)」するとどちらが呼ばれるのか?

ではこの状態でAzure上で「招待」をして管理者を呼ぶと組織アカウントと個人アカウントのどちらが呼ばれるのかというと…、「状況によりまちまち」という恐ろしい状況です。

  1. 招待(権限付与)対象が「xxxx@outlook.jp」等の生粋の個人アカウントの場合には個人アカウントが招待されます。
  2. 招待(権限付与)対象が「xxxx@aa.bb.cc」等の生粋の個人アカウントではないアドレスの場合には組織アカウントが招待されます。

2の場合には、Azure Active Directoryは存在するけれども、招待されたアカウントがまだ存在していない場合には新規にアカウントが作成される動作にすらなります。

招待された側は個人アカウントしか明示的に作っていないのに、気がついたら組織アカウントもできてしまっていて…というような状況にもなりえます。難しいですね。

結局どうしたらいいのか?

色々と複雑なことを書いてしまいましたが、結局どうしたらいいのか?というとそれはとてもシンプルです。

  • 組織アカウントをきちんと作成、管理し、Office 365も利用する、全てのマイクロソフトのクラウドサービスを組織アカウントにて利用し、個人アカウントは組織アカウントと同じアドレスでは作成、使用しない。
  • 個人アカウントがどうしても必要な状況ではxxxxx@outlook.jp等の生粋のマイクロソフトアカウントを作成し、組織のメールアドレスを利用しない。

という状況を作ってしまえば非常にスッキリします。メールアドレスが異なるので全ての場面においてどちらを対象にしているのかも明確にできます。そして組織アカウントを軸として様々なセキュリティ対策や、マイクロソフト系以外も含めてすべてのクラウドサービスを利用するように構成していけばよいのです。

Azureには「規定のディレクトリ」という概念があることもお伝えしました。これも全てのAzureサブスクリプションの既定のディレクトリを組織としてメインで利用しているOffice 365が利用しているAzure Directoryに切り替え、Office 365を使っている組織アカウントでそのままAzureも管理するようにすれば良いです。

結論は非常に単純なので、是非全てのマイクロソフト系のクラウドサービスユーザーがこのような形でディレクトリを構成し、サービスを利用し、不用意なID系のトラブルに巻き込まれないようになることを願っています。

 

 

が、やっぱりちょっと複雑過ぎますよね。色々と不明点やわからない点等あると思いますので、疑問、質問ありましたら以下フォーラム、あるいはtwitter, facebook等にて質問いただければと思います。

なお、あまり複雑なものはお仕事としてご依頼下さい(笑

スポンサーリンク
プロフィール
この記事を書いた人
Microsoft MVP for Cloud and Datacenter Management。「Windowインフラ管理者入門」という本を書きました。Windows系中心のインフラよりの何でも屋。脱原発。エレキベース, ドラムを演奏します。将棋もちょっとやります。
ebiをフォローする
この記事が気に入ったら
いいね!しよう
最新情報をお届けします。
Azure Active Directory
ebiをフォローする
Microsoft Cloud Administrators

コメント