AAD

Azure SQL DBの認証にAzure ADを利用している場合にプログラムからアクセスしたいとします。 Azure AD認証を行う方法は色々とあるのですが、Azure ADにアプリケーションを登録するところから始めると色々と面倒だったりもしますよね、管理者が登録を禁止してたりとか…。 そんな時に一番簡単にできるのはMicrosoft.Data.SqlClientを使ってインタラクティブにAAD認証する方法だと思います。これならアプリケーションのAADへの登録すら必要ありません。 u u n { } s s a i i m n n e g g s c { } p l S M a a y i c s s c e s s { } t r t e o A P a m s z r t ; o u o i s u } f r g c t s t e r r i . S a i n D Q m o n g c a L i g o t D d ( n a B C S n . A M o q . S u a n l O q t i n C p l h n e o e C e ( c n n l n s t n ( i t t i e ) e i r o c ; n c i n t t a n S i ; t g t o i [ r n o ] i n n c a g o r n g = n s ) @ = " S n e e r w v e S r q = l x C x o x n s n q e l c s t e i r o v n e ( r C n o a n m n e e x c x t x i . o d n a S t t a r b i a n s g e ) . ) w i { n d o w s . n e t ; A u t h e n t i c a t i o n = A c t i v e D i r e c t o r y I n t e r a c t i v e ; D a t a b a s e = t e s t d b ; " ; これだけでOKです。 ...

記録する機会があったのでブログにも記録しておきます。 Azure Active Directory管理者の設定 前提条件としてSQL ServerにてAzure Active Directory管理者を設定します。SQL DB自体ではなく、そのDBを稼働させているSQL Server側での設定です。 管理者として指定したAAD上の組織アカウントでSQL Serverにアクセスします。今回はAzure Data Studioを利用しました。 きちんとアクセスできることを確認します。ここではじかれる場合には条件付きアクセスの条件を満たしていないことなどが考えられます。条件付きアクセスの内容も確認してください。 きちんとAADのユーザーでアクセスできることが確認できました。 Azure ADグループの準備 次にAzure AD上にグループを作成し、その中にユーザーをメンバーとして追加しておきます。今回はsqldbaccessというグループにadmin@hccjp.orgというユーザーを追加しました。(アカウントの選択が適当でごめんなさい。) 権限を付与する前に、まずは、アクセスができないことを確認しておきます。 Login failed for user ‘’. と怒られました。AADで認証し、トークンは取得できている状態ですが、権限がなく認可されない場合にはこのようなメッセージが出るのですね。 SQL DBへの権限付与 今回はtestdbというテスト用のDBに権限を出していきます。まずはAAD上のグループに対応するユーザーを作成します。 C R E A T E U S E R F R O M E X T E R N A L P R O V I D E R ; ...

シリーズ記事の7つ目です。M365フルクラウド環境を検証目的で構築しています。下記の記事も合わせてどうぞ！ Windows10をAzure ADに参加させる！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators- Azure ADにドメインを追加してユーザーIDをわかりやすくする！【M365フルクラウド環境検証 その2】 | Microsoft Cloud Administrators- M365 E5検証ライセンスを申し込む【M365フルクラウド環境検証 その3】 | Microsoft Cloud Administrators- Intuneへの登録を行う【M365フルクラウド環境検証 その4】 | Microsoft Cloud Administrators- Windows10のデバイス構成プロファイルを作成して割り当てる！BitLockerでディスク暗号化【M365フルクラウド環境検証 その5】 | Microsoft Cloud Administrators- コンプライアンスポリシーを作成して割り当てる！【M365フルクラウド環境検証 その6】 | Microsoft Cloud Administrators 今回は「条件付きアクセス」にてベースラインポリシーを構成します。 条件付きアクセス 条件付きアクセスは、認証時、クラウドサービスへのアクセス時に色々と柔軟な条件設定を行えますが、「ベースとして設定しておくべき項目」ということでMicrosoftがbaseline policyを用意してくれています。今回はそれを単純に有効化します。 これらの設定によって相当強力にセキュリティが守られることになります。 ただ、やはり管理者自体をロックアウトしてしまう危険性があるので注意が必要です。 多要素認証の構成 Azure AuthenticatorでQRコードをスキャンします。 これで必要な箇所で多要素認証が利用できて大変セキュアになりました。 シリーズの次の記事はこちら！ 条件付きアクセスポリシーを設定してMFAとポリシー準拠デバイスを必須とする！【M365フルクラウド環境検証 その8】 | Microsoft Cloud Administrators

この記事はシリーズの4つ目の記事です。他の記事も参考にしてください！ Windows10をAzure ADに参加させる！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators- Azure ADにドメインを追加してユーザーIDをわかりやすくする！【M365フルクラウド環境検証 その2】 | Microsoft Cloud Administrators- M365 E5検証ライセンスを申し込む【M365フルクラウド環境検証 その3】 | Microsoft Cloud Administrators さて、今回はMicrosoft 365にてデバイス管理を構成していきたいと思います。具体的にはIntuneの話になります。 管理コンソールはどれを使う？ Intuneの構成ならAzure管理ポータルから行うのかな？とも思いますが、Microsoft 365という括りになるとどうでしょうか？こういうときはまずきちんとMicrosoftから提供されているドキュメントを確認したいところですね。 Intune をセットアップするときに、Azure portal でのみ作業してデバイスを管理するか、または Intune と Microsoft 365 を一緒に使用してデバイスを管理するかを選択することもできます。 「Migrating mobile device management to Intune in the Azure portal」(Azure portal でモバイル デバイス管理を Intune に移行する) は Microsoft IT のケース スタディです。 このケース スタディでは、Microsoft IT が最新のデバイス管理アプローチをどのように選択したかを参照し、得られた教訓をお読みください。 Microsoft 365 でのデバイス管理 | Microsoft Docs デバイス管理の管理センターは、モバイル デバイスに関するタスクの管理と実行を行うためのワンストップ ショップです。 このワークスペースには、デバイス管理のために使用するサービス (Intune や Azure Active Directory など) と、クライアント アプリの管理のために使用するサービスが含まれています。 ...

皆さんこんにちは。胡田です。もう2019年ですしもうすぐ平成も終わりますね。私は最近あまりこのブログに記事をかけていませんが元気にやってます。将棋ウォーズがいつまでたっても2級のまま昇級でず苦しんでいます。将棋難しい…。 さて、マイクロソフトのクラウドサービスを利用しているといたるところで「テナント」という言葉を目にします。この「テナント」という言葉は結構曖昧に理解されていることが多く会話の中で様々な誤解を生んでしまう原因にもなっています。 このエントリでは「組織(＝顧客、会社)」と「テナント」の関係について整理しておきたいと思います。 Office 365の「テナント」 例えばOffice 365の契約を考えます。組織としての本番利用を考えるときには「組織」につき1つのOffice 365の環境を作成することが多いです。この時「組織」と「テナント」は1対1の関係となります。 「テナント」というのはサービスの1つの論理的なまとまりです。IDがあり、サービスがあり、データがあります。明示的な許可がなければ「テナント」の中にあるデータは「テナント」内で共有され、外部の「テナント」とは共有されません。 検証用の完全に独立したOffice 365の環境を本番環境とは別で保持したいという組織もあるでしょう。この時1つの組織に対して複数の「テナント」が存在することになります。 このブログでも繰り返し言及していますが、マイクロソフトのクラウドサービスの根幹はAzure Active Directoryにあります。事実上「テナント」というときには「Azure Active Directory」とそれに紐づく各種サービスという意味になります。ですので、「テナント」を指し示すのにはAzure ADのテナント名(xxxxx.onmicrosoft.com)やGUIDを使用します。 例えば私が管理しているhccjp.orgという「テナント」を見てみましょう。下記はAzure管理ポータルからアクセスしたAzure Active Directoryの管理画面です。 このAADはもともと「ebisuda.onmicrosoft.com」というテナント名で取得しました。その後hccjp.orgというドメイン名を追加し、プライマリに変更しています。 このテナントにはOffice 365も連携されています。エンタープライズアプリケーションの一覧を見てもらうとそれがわかります。 HCCJPは個人管理ではありますが、「テナント」としてAADとOffice 365がある状況がおわかりになりますでしょうか。 Azureの「テナント」 Azureに関してはOffice365と異なり、Azureサブスクリプションに対して「ディレクトリの変更」という操作すら行えてしまいますのでAADを軸として1つの「テナント」として考えることはできません。 契約の単位で管理されて入るのですが、サブスクリプションを契約間でコンバートすることもできてしまいます。 Azureに関しては実際のところ「テナント」という表現はほぼ使われないだろうと思います。Azureに関して会話をしている中で「テナント」という言葉が出てきたらそれがAzure Active Directory(＋Office 365, Dynamics 365等)を指しての言葉なのか、Azureのサブスクリプションを指しての言葉なのか等、しっかりとその意図するところを確認する必要があるでしょう。 「テナント」という言葉は注意して使いましょう というわけで、今回はなんだか締まらない内容になってしまいました。それだけ曖昧な言葉であるということです。話し手、書き手の意図をきちんと確認し、思い込みで誤解を生まないようにしていただければと思います。

AADのユーザー一覧をCSVに出力…。 いや、もうこの手のユーザー一覧を出力するスクリプトって何回書いたかもう覚えていないほど何度も何度も書いてます。でも、また今日も書いちゃいました…。 でも、Azure Active Directoryからユーザー情報を抽出してCSVに出力するのは、PowerShellだとすごく簡単に書けますね。別に書いておく必要も感じないくらいに簡単です。VBScriptでゴリゴリ書いていた時代が懐かしいです。 - https://github.com/ebibibi/AzureManagement/blob/master/AAD/ExportAllAADUsersToCSV.ps1

オンプレミスのActive Directory クラウドのAzure Active Directory マイクロソフト系のインフラ管理者にとってオンプレミスの時代に特に重要だったのはActive Directory(以下AD)でした。拙著(Windowsインフラ管理者入門)でも触れたところです。Windowsのドメインという仕組みがあり、そのドメインの中でIDを司るADがあり、アプリケーションはADに対応し、ADに参加したWindowsクライアントからアプリケーションを利用していたのです。 クラウド時代においても依然としてADは重要です。ですが、様々なクラウドサービスを利用し、他の企業とも連携していく必要性が高まる中で、企業内ネットワークに閉じてADのIDのみを利用したシステムだけを利用していればよい時代はとっくに終わりました。 オンプレミスのADをActive Directory Federation Services(以下ADFS)を介して外部とフェデレーションで結ぶという形態での社外ネットワークへの対応もありますが、現在向かっている方向は明らかにAD + ADFSという構成ではなく、クラウド上のIDaaSであるAzure Active Directory(以下AAD)です。AADをID基盤として利用する形態を中心に進化しています。 AADはマイクロソフトが提供するクラウドサービス(Office 365, Azure, Dynamics 365等)のほぼ全てのID基盤となっています。マイクロソフトのクラウドサービスを使っているユーザーは特に意識していなくてもすでにAADを利用しており、クラウド上にIDを保持しています。しかもAADは基本料金無料で提供されています。 また、オンプレミスにADを持つ企業が簡単にAAD上にIDを保持できるように、IDを同期、連携する仕組みも完全に無料で提供されています。 マイクロソフト系のインフラ管理者にとってオンプレミス時代にはADを、クラウド時代にはAADを軸にIDを管理し、そのIDを軸に様々なアプリケーション利用をコントロールすることはほぼ必然であり、まずはじめに抑えておく必要がある部分です。 AADでサービス連携、企業関連系、コンシューマーID連携 AADにはSAML 2.0, WSFederation, OpenConnectID、OAuth 2.0等の業界標準のプロトコルも採用され、マイクロソフトが提供するクラウドサービスにとどまらずインターネット上の様々なサービスと業界標準のプロトコルで連携可能になっています。AzureAD B2B, AzureAD B2C等、企業間の連携やtwitter, facebook等のコンシューマー向けのIDとの連携機能も備えています。 過去、ADを中心としたIDシステムにおいて企業間、グループ企業間でシームレスに連携させることは非常に困難でした。単純にネットワーク的につながっていないものを接続する所から苦労は始まり、個別にシステム毎に連携方法を模索し、ロジックを作り込んでいるケースが多くありました。 クラウド時代には過去と同じような苦労をする必要はありません。IDはインターネット上に存在しており、自由に標準的なプロトコルで連携可能となるのです。 セキュリティ対策 クラウド上にIDシステムが存在することでセキュリティ面の心配をする人も多くいると思います。ですがそれは逆です。むしろクラウド上にIDを保持することの方がセキュリティ面で有利である時代になっています。 クラウドサービスを全く使わずにIDもシステムも完全に社内ネットワークで閉じている状況であれば確かに外部からの攻撃に対しては非常に強いでしょう。入り口も出口も無く、窓を全て締め切っていれば外界から攻撃する手段はありません。それは事実です。ですが、このようにインターネットと分離した環境であったはずの環境においても利便性を求めた結果本来の設計とは異なる構成となってしまい、大規模なセキュリティ事故が起きた実例があります。 このクラウド時代に外部から完全に閉ざした鎖国状態のシステムを作っても生産性高く活動を行えるはずがありません。そうなるとインターネットとの接続をどうしてももつ必要があります。その段階でクラウド上にIDをもつか、オンプレミス上にあるIDに対しての認証の窓口を開かなくてはいけません。 インターネット上に常に存在し、多数の攻撃にさらされながらそれに耐え、しっかりとした運用体制やセキュリティ対策の取られているクラウド上のIDaaSを利用するのと、オンプレミスで自分たちで面倒を見ているシステムとでどちらがセキュリティが高いでしょうか。クラウド上のIDaaSには大量のIDをさばきながら取得できる情報を活用した高付加価値のセキュリティ対策サービスが多数備わっているという現実もあります。ここは人によって意見が分かれる場所かもしれませんが、私見ではあきらかにクラウド上にIDをおいたほうがセキュリティが高くできる現実がすでにあり、今後もその傾向はどんどん強まっていくと考えられます。 むしろ積極的にクラウド上にIDを置き、IDaaSが継続的に進化し続ける機能を把握し、それを有効に活用すべき時代になっていると考えます。 まずAzure Active Directoryの活用から マイクロソフト系のインフラ管理者がクラウドに足を踏み出す際には、個人的なおすすめとして是非AADの活用から考えてもらいたいと思います。AD+ADFSではなく、他社のIDaaSサービスではなくAADを利用してほしいです。 AADはマイクロソフトのクラウドサービスの根幹となり、全てのシステム、全ての仕組みに関連するものだからです。 そして、AADは無料でありいくつでも作成できるものなのですが、「本番AAD」を1つ作成し、基本的に全てのものをそこに紐付ける形にすることをお勧めします。つまりそれはシステム毎にID、Passwordを別々に作成して分割する…ということをしないようにするということです。私のおすすめは全て、例外なくです。他社製のクラウドサービスを利用するときですらです。 この構成をお勧めするのには様々な理由があり簡単に言い表すことは難しいのですが「1つのIDを利用して全てのものを利用可能とするのが最も便利でセキュアで運用コストが低いから」です。この点はもっと説明が必要ですのでまた今後のブログエントリで解説していきたいと思います。

皆さんこんにちは。胡田です。 ADFSでクレームルールを書いて様々なコントロールを行う…ということは技術的に可能なのですが、ものによっては意味がない、正しくない実装になってしまいますので注意してください。 例えば1例として、User-Agentを用いてアクセスをコントロールするような実装があります。ぐぐると解説記事もいっぱい出てきます。例えば以下。 - Restrict iOS apps which can access to Office 365 services (ADFS required) – beanexpert ADFSのクレームルールでuser agent(x-ms-client-user-agent)を参照してそれが特定の値であれば許可/拒否する…ということが開設されています。 これははっきり言ってひどい実装です。 HTTP(S)プロトコルにおいて、User-Agentヘッダはクライアントアプリが任意の値を埋め込むことが非常に簡単に行えるものです…、というかそもそもが自己申告制のものでして…こんなものを信じてなにかをコントロールするというのは「あなたは犯罪者ですか？」という質問の答えで許可/拒否するようなものです。 例えば「user agent change」というキーワードあたりでちょっとググるだけでも山ほどツールや手法が出てきます。 - user agent change - Google 検索 例えばProxyで書き換えるようなことも簡単にできますね。 - user agent change proxy - Google 検索 このあたりはHTTPプロトコルがそもそもどんなものなのか、ということを知っていれば当たり前に分かる話ではありますが…。 何をどのポイントでコントロールするか、というのはなかなかに難しいトピックではありますが、ADFSで色々とコントロールしようとするのは、Microsoftの今後の方向性からいっても相当の悪手だと思います。 MicrosoftソリューションであればAzure AD Premium( + Intune)を活用するのが吉だと思います。

久しぶりにブログをまともに書きます。リハビリです。 今回のネタは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です。 ...

寒い週末になりました。さて、今週のトピックスです。 - arm and api for creation and managing OMS – Customer Feedback for Microsoft Azure 1 user We would like to add new OMS Workspaces using arm templates or powershell api. That way we could fully automate the creation of OMS f… [feedback.azure.com ](http://b.hatena.ne.jp/ebibibi/?url=http%3A%2F%2Ffeedback.azure.com%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, oms, arm, powershell 28 clicks 2017/01/20 - OMS Security malware assessment adds support for more antimalware vendors – Operations Management Suite Blog 1 user FAST FACT : OMS Security is adding support for Symantec Endpoint Protection and Trend Micro Deep Security to its Antimalware assessme… ...

金曜日の帰りの電車で座席に座れたので、Surfaceを取り出してこのブログを書いています。最近ブログ記事を全然書けていないので書きたいことがたくさんたまっております…。 さて、今回の話題はAzure Active Directory(AAD)です。オンプレミスのActive Directoryは知っていてもAzure上のActive Directoryの事を概念的に理解出来ている人はまだまだ少ないのが現状ではと思います。私が理解しているところをいくつか書いておこうと思います。一部正確ではない表現をあえて書いている部分がありますし、私の理解がそもそも間違っている部分があるかもしれません。ですが、まずはこういう理解から入ると良いだろうと思っています。 - オンプレミスのActive Directory Domain Service(ADDS)と似た名前がついてますし、機能的に同じ部分も一部ありますが、当初の理解のためには「名前は似てるけど現状は完全な別物」という捉え方をするのがよいだろうと思います。(将来的には同じような形に収束するのかもしれません。むしろクラウド上のみで完結する形になるのかもしれません。どういう方向に行くか、ワクワクしながらウオッチする感じです。) - AADはクラウド上にあって、インターネットに公開されていて、インターネット上での外のサービスとの連携を主眼に機能が用意されています。 - AADにはユーザーやグループ等が登録できます。 - O365のユーザー情報はAADに格納されています。例えばExchange OnlineはディレクトリとしてO365のテナント用に用意されたAADを利用しています。 - AADはAzure上のサービスとして存在しているので、いくつでもテナントを作成することができます。 - Microsoftアカウントはマイクロソフトが用意してくれていて全世界に公開されている1つのAADテナントです。 - AADのテナントは開かれているので、AADの1つのテナントに別のAADのテナントのユーザーを登録して権限を付与する…というようなことも可能です。 - AADとオンプレミスのADDSは「ディレクトリ同期ツール」にて同期することが可能です。 同期は基本的にADDSからAADの方向のみです。 - パスワードに関してはAADからADDS方向の同期も実装されてきました。今後も増えていくのかもしれません。 - AADの管理は複数の場所から行えるのですが、一番充実した管理が行えるのはAzureの管理ポータル画面からです。 - O365のAADも1つのAADなので、Azureの管理ポータル画面からO365で利用しているAADを「追加」して管理することができます。 - AADに機能を追加したAzure AD Premiumというサービスがあります。これはAzureの管理ポータルから管理します。O365の管理ポータルからは管理できません。 超簡単なまとめとしてはオンプレミスのID管理はAD DS。クラウドのID管理はAAD。間のID同期はディレクトリ同期ツール。というあたりで良いのかなと思います。 ADFSは?という声が聞こえてきそうですが、一旦ADFSを絡めずに理解するのが良いのではと思います。 ADDSの理解。AADの理解。ADFSの理解。これらを単体で理解した上で、この3つをつなげた時に行える世界の広がりを理解すると感動的だと思います。 もっとちゃんと時間をとって書きたいですね…。