【失敗回避！】Microsoftのクラウドサービスを使うならこれだけは知っておかないとまずいこと

すでにAzureを使っている場合に正しいEntra IDでM365を契約する方法 この記事の内容 AzureをすでにAzureを利用しているユーザーが、同じEntra ID（Azure Active Directory）をMicrosoft 365でも使う方法を解説します Active DirectoryとAzure Active Directory（Entra ID）は別物であることを押さえます M365契約時に使うべきユーザーアカウントの選び方と、誤ったテナントに紐付いてしまう事故の防ぎ方を紹介します メールリンク経由（Enterprise Agreement系）で契約する際の注意点を説明します 万が一間違えてしまった場合の対処法も触れます 前提：Active DirectoryとAzure Active Directoryは別物 まず用語を整理しておきます。「AD」と略されることがありますが、Active Directory（オンプレミス）とAzure Active Directory（Entra ID）は完全に別の製品です。 Active Directory：Windows Serverで構成するオンプレミスのディレクトリサービス Azure Active Directory（Entra ID）：Microsoft Azureをはじめとするクラウドサービスで使用するクラウドベースのディレクトリサービス 今回の記事では後者、クラウド上のEntra ID（Azure Active Directory）を対象として説明します。 やりたいこと：Azureで作成済みのEntra IDをM365でも使う AzureをフリープランなどでサインアップするとEntra IDのテナントが自動的に作成されます。その既存のEntra IDテナントをMicrosoft 365の契約にも紐付けたい、というのが今回のシナリオです。 結論から言えば、これは可能です。ただし、手順を誤ると意図しない新しいEntra IDテナントが作成されてしまうリスクがあります。正しい手順を確認していきましょう。 手順1：使用するEntra IDのテナント情報を確認する まず、Azureポータルで自分が使いたいEntra IDのテナント情報を確認します。 Azureポータル（portal.azure.com）にサインインします 検索バーで「Azure Active Directory」または「Entra ID」と入力してクリックします 概要画面で以下の情報を控えます - - - テ テ プ ナ ナ ラ ン ン イ ト ト マ 名 I リ （ D ド 表 メ 示 イ 名 ン ） 名 （ 例 ： c o n t o s o . o n m i c r o s o f t . c o m ） このテナントIDとプライマリドメイン名を把握しておくことで、作業中に「どのEntra IDを使っているか」を間違いなく確認できます。 ...

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 サービスを使用する際には、次のような手順が必要になります。 Azure グローバル（Azure クラウド）を選択する 画面に表示されたコードをコピーし、デバイスログイン画面に入力する 組織のアカウントでサインインする Azure Active Directory のテナント ID を選択する Azure AD 上にアプリケーションを新規作成するか、既存のものを使用するかを選択する この流れで「新規作成」を選択すると、一般ユーザーの場合に次のようなエラーが表示されることがあります。 ア プ リ ケ ー シ ョ ン は A z u r e A c t i v e D i r e c t o r y に 登 録 で き ま せ ん で し た なぜエラーになるのか？ このエラーの原因は、Azure AD の管理画面にあります。 ...

Azure AD と CSP契約の関係 ─ Microsoft クラウドサービスを使うなら知っておきたいこと この記事の内容 CSP（クラウドソリューションプロバイダー）契約とは何か、その仕組みを解説します Azure AD テナントと CSP 契約の正しい関係性と理想的な構成を説明します CSP 契約時に Azure AD が複数になってしまいやすい問題点と原因を紹介します Azure AD が複数存在する状態でのリスクと、サブスクリプション移行の難しさを解説します 適切な CSP 契約のために確認すべきポイントと、プロへの相談が必要なケースをまとめます CSP契約とは何か CSP とは、Cloud Solution Provider（クラウドソリューションプロバイダー）の頭文字をとったものです。Microsoft のクラウドサービスを Microsoft と直接契約するのではなく、CSP ベンダーと契約を結んでそのサービスを利用するという形態です。 CSP 契約を利用することで、Azure、Microsoft 365、Dynamics 365 などの Microsoft クラウドサービスを CSP ベンダー経由で使えます。また、CSP ベンダー独自のサービスを利用することも可能です。 CSP 契約の本来のメリットは、環境構築から日常管理、Microsoft とのサポート対応まで、CSP ベンダーがすべてを面倒みてくれる点にあります。顧客側は、CSP ベンダーが提供するサービスを利用するだけでよく、問題が発生した場合も CSP ベンダーに問い合わせるだけです。一方、Microsoft と直接契約した場合は、自分たちで契約・管理・問題解決をすべて行う必要があります。 Azure AD の理想的な構成（おさらい） CSP 契約の話に入る前に、Azure AD の理想的な構成を確認しておきましょう。 理想は、1つの Azure Active Directory にすべてのユーザーが存在している状態です。そのひとつの Azure AD に対して、ライセンスが割り当てられ、Azure サブスクリプションも紐付いており、セキュリティやガバナンスを効かせながらすべてのサービスが使える状態が理想です。また、Microsoft 以外の SaaS サービスへも同じ ID でサインインできることが望ましい姿です。 ...

組織アカウントと個人アカウントの違い — Microsoftクラウドを使うなら知っておくべきこと この記事の内容 Azure Active Directory のユーザーアカウントは「組織アカウント（職場または学校のアカウント）」と呼ばれます Microsoft アカウントは「個人アカウント（MSA）」と呼ばれ、個人向けに設計されています 同じメールアドレスで両方のアカウントが同時に存在できるため、混乱が生じやすいです 企業での利用は必ず組織アカウントを使うべきであり、個人アカウントを業務に流用してはいけません この2種類の違いを正しく理解することが、Microsoftクラウドを安全・正しく使う前提条件です はじめに：シリーズ第3弾 この記事はMicrosoftクラウドサービスを使うために知っておくべき基礎知識を解説するシリーズの第3弾です。 第1弾：Azure Active Directory（AAD）とテナントの関係 第2弾：Azure Active Directoryが複数存在できること、および外部ユーザーの招待（Azure B2B） 第3弾（本記事）：組織アカウントと個人アカウントの違い 今回のテーマは、Microsoftクラウドにおける「アカウントの種類」を正しく理解することです。混乱されている方が非常に多い、本質的な内容です。 3種類のユーザーアカウント 前回の解説では、あるテナントのユーザーが別テナントのユーザーを招待できる「Azure B2B」の仕組みを紹介しました。この仕組みによって、1つのテナントの中に次の2種類のユーザーが存在できます。 テナント内部のユーザー：そのAzure Active Directoryに直接存在するユーザー ゲストユーザー：外部のAzure Active Directoryから招待されたユーザー これに加えて、第3の種類があります。それが「Microsoft アカウント（個人アカウント）」です。このMicrosoftアカウントをAzure Active Directoryに招待して権限を付与することもできます。たとえばTeamsへのアクセスや、SharePoint Onlineのサイトへのアクセスも、招待されたMicrosoftアカウントから行うことが可能です。 2種類のアカウントの正式名称 それぞれの別名・略称を整理しておきます。 アカウントの種類 別名・呼び方 Azure Active Directory のユーザー 組織アカウント / 職場または学校のアカウント Microsoft アカウント 個人アカウント / MSA（Microsoft Account の略） Microsoftの公式ドキュメントやUIには「職場または学校のアカウント」という表現が頻繁に登場します。これがAzure Active Directory内のユーザーを指すことを覚えておいてください。 技術ブログなどで「MSA」という略称を見かけた場合、それはMicrosoftアカウント（個人アカウント）のことです。 2種類のアカウントの違い 作成コストとライセンス どちらのアカウントも無料で作成できます。ただし利用できるサービスの範囲が異なります。 組織アカウント（Azure Active Directory） Azure Active Directory自体は無料で作成可能 メールなどのサービスを利用するには別途ライセンスの購入と割り当てが必要 例：Exchange Onlineを使うにはExchange Onlineのライセンス、Teamsを使うにはTeamsのライセンスが必要 一般的にはMicrosoft 365のサブスクリプションをまとめて購入して割り当てる形が多い 個人アカウント（Microsoftアカウント） ...

テナントを超えたコラボレーションとゲスト管理について【Azure B2B】 この記事の内容 Microsoft 365 / Azure では、テナントをまたいだコラボレーションに「ゲスト招待（Azure AD B2B）」を使う 外部ユーザーを別テナントに新規ユーザーとして作成する方法は推奨されない ゲストとして招待することで、招待された側は自分のアカウントをそのまま使い続けられる Microsoft Teams からでも Azure AD 管理センターからでも招待操作が可能 ゲストユーザーも自組織ユーザーと同様にライフサイクル管理が必要 テナントをまたいだコラボレーションの課題 前回の動画でお伝えしたとおり、Microsoft 365 や Azure では「テナント」という単位があり、その中に Azure Active Directory（Azure AD）が一つ存在します。ライセンスが割り当てられたユーザーはその Azure AD 内に作成され、各種サービスへのアクセス権もこの Azure AD 内のユーザーに対して付与される構造になっています。 では、異なるテナントに所属する A さんと B さんが、同じ Microsoft Teams のグループで一緒にチャットしたり、ファイル共有や会議をしたりするにはどうすればよいでしょうか。 テナント内の Azure AD に存在するユーザーにしかアクセス権を付与できない以上、これをそのまま実現することはできません。この問題を解決する方法を見ていきましょう。 推奨されない方法：別テナントに新規ユーザーを作成する 一つの解決策として、A 社のテナントに B さんのユーザーを新規作成してしまうという方法があります。しかしこの方法は 推奨されません。 B さんは自分の組織のアカウントと、A 社テナント上のアカウントを使い分けなければならなくなります。Teams クライアントを使う際も、一度サインアウトして別のアカウントでサインインし直す操作が必要になり、非常に使い勝手が悪い状態になってしまいます。 推奨される方法：ゲストとして招待する（Azure AD B2B） 上記の問題を解決するのが Azure AD B2B の機能です。外部テナントのユーザーを「ゲスト」として自テナントの Azure AD に招待することができます。 ゲストとして招待された B さんは、自分の組織のアカウントをそのまま使い続けることができます。A 社の Azure AD 内にも B さんがゲストユーザーとして存在するようになるため、同じ Teams グループにアクセス権を付与することが可能になります。 ...

Azure AD とテナントの関係 — Microsoft クラウドサービスを使うなら絶対に知っておくべきこと この記事の内容 Microsoft 365 を契約すると Azure Active Directory（Azure AD）が自動的に作成され、ライセンスとユーザー管理の基盤になります Azure はユーザー単位のライセンスではなく従量課金のため、Azure AD との紐付け方が M365 とは異なります Azure のサブスクリプションは別の Azure AD に付け替えができるという、他のサービスにはない特徴があります 何も意識せずに進めると Azure AD が複数作られてしまい、セキュリティ管理・コスト・運用に問題が生じます 組織では Azure AD を 1つに統一する ことが強く推奨されます Microsoft 365 契約時に起きていること Microsoft 365 を契約すると、まず Azure Active Directory（Azure AD）が1つ作成されます。これを意識していない方も多いですが、Microsoft 365 を使っている以上、Azure AD を使っていないということはありません。必ず紐付きます。 その構造は次のとおりです。 Azure AD が作成される 購入したライセンスが Azure AD に紐付く Azure AD 内にユーザー（組織アカウント）を作成する ユーザーにライセンスを割り当てる ライセンスを持つユーザーが各サービスを利用できるようになる たとえば Exchange Online を契約すると、ライセンスを割り当てられたユーザーにメールボックスが作成されます。Dynamics 365 や Power BI を追加契約した場合も同様に、そのライセンスを Azure AD に紐付けてユーザーに割り当てることでサービスが使えるようになります。 ...