O365

以前の記事に続いてMicrosoftのクラウドサービスを使うならこれだけは知っておかないとまずいこと その2です。前提としてAzure Active Directoryと「テナント」の関係を理解している必要がありますので前回のエントリが未読の方はそちらから先に読んでいただけると嬉しいです。 https://cloud.ebisuda.net/2021/09/23/azure-ad%e3%81%a8%e3%80%8c%e3%83%86%e3%83%8a%e3%83%b3%e3%83%88%e3%80%8d%e3%81%ae%e8%a9%b1-microsoft%e3%81%ae%e3%82%af%e3%83%a9%e3%82%a6%e3%83%89%e3%82%b5%e3%83%bc%e3%83%93%e3%82%b9%e3%82%92%e4%bd%bf/ 今回は前回の内容を踏まえた上で、「テナントをまたいだ外部組織とのコラボレーション」の仕組みについての解説です。自テナントのAzure Active Directoryにユーザーを作成するのではなく、ゲストとして招待し、さらにそのゲストのライフサイクル管理もきちんとしましょうねというお話です。 このエントリの内容はYoutubeの動画にもしていますので、動画の方がお好みの方は動画でご覧ください。 https://www.youtube.com/watch?v=lpatFbZnJyg テナントにはAzure ADが1つ テナントにはAzrue ADが1つです。Azure AD内にユーザーがあり、そのユーザーに対して各種サービスにアクセス権を付与することも可能です。 これは組織の外部も同様です。下図は2つの組織がそれぞれ独立している様子だと思ってください。 テナントをまたいだコラボレーション この時にAさんとBさんが一緒に作業したいことってありますよね。 AさんとBさんが同じTeamsのグループメンバーとしてチャットをしたりファイルを共有したり会議をしたりしたいわけです。でも、別々の異なるテナントに存在するAさんとBさんなのでこのままではコラボレーションできません。権限はテナントにあるAzure AD内に存在しているユーザーにしか出すことはできないのです。 コラボレーションするための良くない方法 コラボレーションをするための1つの方法として「新規にユーザーを自テナント内に作成する」という方法があります。下の図のような状況にする方法です。 この例ではAさんと同じAzure ADに、Bさんを新規にユーザーとして作成しています。こうしてしまえば確かにAさんとBさんはコラボレーションできるようにはなるわけですが、色々と良くないこともあります。 (左のテナントの)Bさんのために有償のライセンスを別途割り当てる必要がある。- Bさんは2つのアカウントの両方にきちんと異なるパスワードを設定する等適切に管理する必要がある。- Bさんはアカウントを切り替えるときには、サインアウトやサインインを繰り返す必要がある。 個人的にもこの構成は極力避けるべきと思います。 推奨構成：ゲストとして招待 推奨する構成は「ゲストとして招待する」です。これはAzure B2Bという名前がついています。 外部組織のユーザーもAzure ADであれば「ゲストとして招待」することができるのです。これは事実上「ゲストユーザーアカウントを自テナント内に作成する」というような感じです。招待された側は1つのアカウントで複数のテナントにアクセスすることが可能となります。 これはM365系でもそうですし、Azureでも同じです。 Active Directoryの時代にはこのような「他のテナントのユーザーに権限を出す」というようなことをするのはかなりハードルが高かったですし、完全に外部組織となれば不可能に近いところもありました。ですが、クラウド時代になってユーザーのメールアドレスだけ入力すれば簡単に外部のユーザーを招待して権限を付与することができるようになりました。これはものすごい技術革新です。 どれだけ簡単にできるのかは、実際のデモを見てもらうとわかりやすいです。是非動画でご覧ください。 https://www.youtube.com/embed/lpatFbZnJyg?start=313 ゲストの「ライフサイクル管理」も必要 良いことづくめのゲスト招待ではありますが、これによってオンプレミスのActive Directoryの時には存在しなかった「ゲストのライフサイクル管理」というタスクが発生します。 目的に沿うようにゲストを招待しつつ、ゲストのライフサイクル管理を行うのも招待元テナント管理者の仕事になります。 だれがゲストを招待するのか?(設定によってコントロール可能)- ゲストはどこに対して権限を持つのか?- いつ、ゲストは権限を無くすのか?- いつ、ゲストアカウントは削除されるのか? Azure ADのエンタイトルメント管理の機能などを用いてゲストユーザーを管理することが理想的です。 https://docs.microsoft.com/ja-jp/azure/active-directory/governance/entitlement-management-external-users まとめ テナント内のサービスにはテナント内のAzure ADに存在しているユーザーしか権限を出すことができない- Azure ADにはゲストを招待する機能がある(Azure B2B)- 招待することも招待されることも可能- 自組織のユーザーやグループと同じように、ゲストのライフサイクル管理が必須 オンプレミス時代のActive Direcotryにはできなかった「外部のユーザーを招待する」という機能をうまく使って企業間のコラボレーションを実現しましょう!

複数の人から「自分自身からメールが届いた、乗っ取られてしまっているのだろうか？」という話をもらいましたので、「そうではないですよ」ということを動画で実際に実演もしながら解説してみました。 今回のネタは動画のほうが伝わりやすいかな？と思って動画にしてみましたが、文章のほうがサクッとすばやくポイントできますので、要点は以下に。 認証なしでメールを送信することができる(※認証が必要なケースもありますが歴史的にみても認証なしのほうが大部分です。)- 「送信者」の設定は単に文字列で指定するだけでありいくらでも自由に設定できる。- 心配だったらメールヘッダで送信元を確認できる 実際のやり方は動画を参照してみてください。 最近ちょっと時間的な余裕ができたことやYoutubeでのライブ配信のやり方を覚えたこともあり、リアルタイムに質問を受けながらそれに回答するようなこともできると嬉しいなと考えています。「それだったらこういうテーマの話をしてほしい」などあれば、コメント、Twitter等でリクエストもらえると嬉しいです。

久しぶりにブログをまともに書きます。リハビリです。 今回のネタはCloud Solution Providerへの顧客テナント作成時のバリエーション…ということで、完全にエンタープライズの、さらにCSP Directパートナーにかなり特化した話なので一般向けではないですが…。それでも、結構色々なしくみの勉強や頭の体操にはなりますので面白くはあると思います。 ただ、私も全部完全にわかっているわけではなく、また、使用の変化も結構ある領域なので、話半分に読んでいただければと思います。何かしら保証するものではありませんし、間違っていても責任とれません。すいません。 そして結論めいたものはなく「状況によってベストな解法は変わる」という意見です。すいません。 Cloud Solution Providerとは Cloud Solution Provider、略してCSPは簡単に行言ってしまうと、マイクロソフトのクラウドソリューション(Azure, O365, Dynamics等)を顧客に対して提供するものです。 参考：マイクロソフト クラウド ソリューション プロバイダーの概要 マイクロソフトのクラウドソリューションなんだからマイクロソフトから買うんじゃないの？という疑問が出ると思いますが、もちろん「顧客⇔マイクロソフト」という形で顧客とマイクロソフトとの間で直接販売する形態が基本です。これもクレジットカードだけあればすぐに購入して使いはじめられるダイレクト販売があったり、企業としてEnterprise Agreement契約の中で購入したり…など色々とやり方があります。 でも、マイクロソフトはパートナービジネスに積極的ですし、特に日本では企業としてどこかのSIerなりCIerなりにシステム構築を依頼する形態が多いです。これに対応するのがCSPです。「顧客⇔SIer/CIer⇔マイクロソフト」という形態となります。 顧客はCSPであるSIer/CIerから「サービス」を購入し、SIer/CIerは裏でマイクロソフトのクラウドサービスを活用してそのサービスを提供する、ということです。顧客からはマイクロソフトは全く見えない形となります。何かあった場合のサポートはSIer/CIerが対処します。顧客からマイクロソフトに直接のサポートを要求することはある意味では「できない」ということにもなります。 このあたりのビジネス形態の話はこのブログエントリの趣旨ではないので、このへんで…。 クラウド時代のID管理はAzure ADである マイクロソフトテクノロジーにおいてオンプレミス時代のID管理の中心はActive Directoryでした。そして、クラウド時代のID管理はAzure Active Directoryです。 これはもちろんCSPにも当てはまります。 CSPプロバイダー(SIer/CIer)がCSP関連を管理する「パートナーポータル」には「顧客」という概念があるのですが、「顧客」それぞれはAzure Active Directoryのテナントに１対１で対応します。 たとえば「顧客」を新規作成する際には自動的にAzure Active Directoryテナントが作成されます。ドメイン名の指定が必須です。 あるいはすでに企業でO365を使用している等の状況がありAzure Active Directoryテナントを保持していればそれと紐付ける「再販業者関係の要求」というオペレーションもあります。 マイクロソフトのクラウドサービスは全てAzure Active Directoryに紐付いています。これをキーとして理解しなければいけませんし、CSPプロバイダーはActive Directory Directoryの設計を行わなければいけません。顧客としてもIDの管理は非常に重要ですので、CSPサービスを利用する時にそのIDをどのようにするのか(既存のAADを使うのか、新規にAADを作成して別管理とする(≒CSPベンダーに任せる))のかを選択しなくてはいけません。 Azure Active Directoryとマイクロソフトのクラウドサービスの関係 Azure Active Directoryとマイクロソフトのクラウドサービス群の関係はきちんと前提知識として理解しておく必要があります。 まず、企業としては唯一の本物の…とでもいうような１つのAzure Active Directoryを保持することになります。これは企業としてEA契約でマイクロソフトのクラウドサービスを購入した時に自動的に作成されます。例えばO365やDynamics 365の契約をするとその契約に紐付いて作成されます。ではAzureの契約をした時には？ここは歴史的経緯があり、タイミングによりまちまちの状況という認識です。ここは正確なことをわかっていないのであまり触れないことにしますが、Azureには複雑になってしまう理由となる機構があります。 Azureサブスクリプションの「規定のディレクトリ」 Azureサブスクリプション(≒Azure環境)には「規定のディレクトリ」という概念があり、さらにこれが「変更」できちゃうんです。歴史的にはそもそもこれができない時期もありましたし、マイクロソフトアカウントしか使えない時期もありまして…、それで色々と複雑な事になっています。私も過去に色々と苦労してましてブログエントリも結構書いてますね。 Azureサブスクリプションの既定のディレクトリをO365で利用しているAzure Active Directoryに変更する方法 | Windowsインフラ管理者への道 - AzureサブスクリプションとAzure Active Directory周りの質問への回答 その1 | Windowsインフラ管理者への道 - Azureサブスクリプションと規定のディレクトリの関係(Visual Studio Team ServicesでO365で利用しているAADディレクトリと紐付けようとしてはまった) | Windowsインフラ管理者への道 - Azureのサブスクリプション, ディレクトリ, 組織アカウント, マイクロソフトアカウントあたりの理解におすすめのMVAコンテンツ | Windowsインフラ管理者への道 「Azureサブスクリプションへの権限追加は「既定のディレクトリ」に存在している組織アカウントしか対象にできない」という制約事項があり、それをまず抑えておく必要があります。 ※実はAzureとしては上記の制約にはさらに例外がありまして…(サービス管理者がマイクロソフトアカウントなのか、組織アカウントなのかで挙動が変化します。)、それがさらに話をややこしくするのですが、CSPの文脈ではまずこの制約事項を抑えておけばOKです。 ...

Announcing Azure Network Watcher – Network Performance Monitoring and Diagnostics Service for Azure | Blog | Microsoft Azure 1 user Have you ever felt the need to diagnose a critical problem and you needed access to packet data from a virtual machine? What if you c… [azure.microsoft.com ](http://b.hatena.ne.jp/ebibibi/?url=https%3A%2F%2Fazure.microsoft.com%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, azure 16 clicks 2017/03/23 - System Center Configuration Manager エージェントと Microsoft Intune (MDM) による管理の共存について – Japan System Center Support Team Blog 1 user みなさま、こんにちは。System Center サポート チームです。 Windows 10 の展開に伴い、タブレットなどのモバイル デバイスに搭載された Windows 10 端末の管理をご検討いただく中で、System Center Configuration… ...

卒業式シーズン真っ只中、今週のトピックスです。 - CSP における OMS の使用について【3/15 更新】 – Microsoft Partner Network ブログ 2 users （この記事は 2017 年 2 月 17 日にHybrid Cloud Best Practices blog に掲載された記事 OMS in CSP の翻訳です。最新情報についてはリンク元のページをご参照ください。) クラウド ソリューション プロバイダー (C… [blogs.technet.microsof... ](http://b.hatena.ne.jp/ebibibi/?url=https%3A%2F%2Fblogs.technet.microsoft.com%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, csp, oms, azure 18 clicks 2017/03/17 - Announcing Azure SQL Database Premium RS, 4TB storage options, and enhanced portal experience | Blog | Microsoft Azure 2 users Get credits that enable: 4 Windows or Linux Virtual Machines 24 x 7 for a month And much more… Learn more ...

寒暖の差が激しい1週間でした。さて、今週のトピックスです。 - 「OneDrive」待望の差分同期、2Qに実現へ–マイクロソフトの新ロードマップ - ZDNet Japan 9 users Microsoftは2016年2月に「OneDrive」のロードマップを公開した際、差分同期機能（ファイルを同期する際に、ファイル全体ではなく、変更された部分のみをその対象とする機能）について、実現すると明記していた。ただ、一般提供を開始する時期については具体的に言… [japan.zdnet.com ](http://b.hatena.ne.jp/ebibibi/?url=https%3A%2F%2Fjapan.zdnet.com%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, onedrive 34 clicks 2017/02/23 - Ability to mention collegue in comments section – Planner Customer Feedback 1 user Anonymous shared this idea · Jan 22, 2016 · Flag idea as inappropriate… Flag idea as inappropriate… Delete… · Admin → ...