Azure Active Directory

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です。 ...

以前の記事に続いて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にはできなかった「外部のユーザーを招待する」という機能をうまく使って企業間のコラボレーションを実現しましょう!

Microsoftのクラウドサービスを利用すると裏では必ずAzure ADが使われています。Azure ADを中心にして組織が利用可能な「テナント」が構成されるわけです。あまりにも重要な事なのですがあまりにも重要すぎて自動的にAzure ADが生成されることもあり、きちんと意識していない組織があります。 よくわかっていない状態で別のMicrosoftのクラウドサービス、特にAzureの利用を開始するととても変な構成になってしまい、修正するのにとても時間と手間がかかってしまうことにもなりかねません。 特に管理者の方、Microsoft 365やAzureの契約を担当する方はしっかりとAzure ADとテナントの関係を理解してから契約を進めてください。 Youtubeでも解説していますので、ブログでも動画でもお好きな方をご覧ください。 https://youtu.be/x2hkwqt-K80 Microsoft 365を契約したらどうなるか？ まず、Microsoft 365を契約したらどうなるかという話をしましょう。 Microsoft 365を契約する時には必ずAzure Active Directoryがセットです。Azure ADが存在します。あるいは存在しなければ作成されます。 そして、Azure Active DirectoryにM365のライセンスが紐づきます。1つの契約で入手したライセンスをどこでも好きな複数のAzure ADに割り当てることはできません。1契約で100ユーザー分購入し、50ユーザー分をAAD1に、30ユーザー分をAAD2に、20ユーザー分をAAD3に…というようなことはできないのです。 Azure Active Direcotryにはユーザーやグループを作成できます。そして、そのユーザーにライセンスを割り当てます。M365のライセンスはユーザーに割り当てるライセンスなのです。 ライセンスを割り当てられたユーザーはMicrosoft 365の様々なサービスにアクセス可能となります。 この時に、Azure Active Direcotryを中心として、ユーザーが存在し、様々なサービスが使える範囲を「テナント」と呼びます。「テナント」といえば1組織が利用しているサービスの範囲が明確にわかるわけです。 Microsoft 365においては… 1テナント内にAzure Active Direcotryは1つだけ存在する- 契約したライセンスはAzure Active Direcotryに紐づく- ライセンスはユーザーに付与される ということになります。 やろうと思えば同一組織が複数のMicrosoft 365の契約を行うことも可能ですが、その場合にはテナントが2つになります。 1企業が2つの契約をし、テナントを2つもつ…ということは通常行いませんが、やろうと思えばできます。ですが、それぞれのテナントは別の環境です。技術的にはほかの企業がMicrosoft 365の契約をしているのと何も変わりません。 ユーザーにライセンスを割り当てるサービス群はすべて一緒 ここまで、Microsoft 365を例として記載してきましたが、これはほかのサービス群でも同じです。Azureのみが唯一の例外です(後述します)。 Dynamics 365でも、PowerBIでも、契約をしてライセンスを入手するとそれはAzure Active Direcotryに紐づき、Azure Active Direcotry内のユーザーにライセンスを付与し、ライセンスを持ったユーザーがサービスを利用することができます。 間違ったテナントにライセンスを紐づけてしまわないように注意 テナント内にAzure Active Direcotryは1つだけですので、テストで作ったAzure Active Direcotryに本番用のライセンスが紐づいてしまわないように注意してください。 テスト用の適当な名前のAzure Active Directoryをそのまま本番利用するのは事実上問題ないとはいえ、やっぱり気持ちが悪いですよね。 ...

シリーズ記事の18個目です。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- 「条件付きアクセス」で「ベースラインポリシー」を設定する！【M365フルクラウド環境検証 その7】 | Microsoft Cloud Administrators- 条件付きアクセスポリシーを設定してMFAとポリシー準拠デバイスを必須とする！【M365フルクラウド環境検証 その8】 | Microsoft Cloud Administrators- Microsoft Defender ATPを実装する！【M365フルクラウド環境検証 その9】 | Microsoft Cloud Administrators- Office Pro PlusをIntuneから配布する！【M365フルクラウド検証環境 その10】 | Microsoft Cloud Administrators- Exchange Onlineのドメイン設定とメール配送の挙動【M365フルクラウド検証環境 その11】 | Microsoft Cloud Administrators- AutoPilotを構成する！【M365フルクラウド検証環境 その12】 | Microsoft Cloud Administrators- iOS用の接続構成を設定する！【M365フルクラウド環境検証 その13】 | Microsoft Cloud Administrators- Android用の接続構成を設定する！【M365フルクラウド環境検証 その14】 | Microsoft Cloud Administrators- Windowsストアアプリを強制配信する！【M365フルクラウド環境検証 その15】 | Microsoft Cloud Administrators- セルフサービスリセットを構成する！【M365フルクラウド環境検証 その16】 | Microsoft Cloud Administrators- Windows 10 更新リングを構成する！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators 今回はMSI形式のインストーラーのアプリケーションをWindowsに展開します。具体例としてBox Driveを配信してみます。 ...

この記事はシリーズの3つ目の記事です。他の記事も参考にしてください！ Windows10をAzure ADに参加させる！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators - Azure ADにドメインを追加してユーザーIDをわかりやすくする！【M365フルクラウド環境検証 その2】 | Microsoft Cloud Administrators さて、今回はIntuneでデバイス管理の入り口を…と思っていたのですが、よく考えたらまず評価ライセンスを申し込まないといけませんでした。というわけで、今回は全部入りライセンスのM365 E5のトライアルを申し込んでみたいと思います。 Microsoft 365 E5トライアル申し込み まずMicrosoft 365 E5トライアル申し込みをするための管理者ユーザーを作成します。もともとのAzure ADを作成したユーザーが管理者になっているのですが、別のAADディレクトリから招待されたユーザーであり少々心配なため…。 そして、新規のAAD管理者であるadmin@tm-plan.netにてMicrosoft 365管理センターにアクセスします。 Microsofot 365 E5の試用を開始します。 ロボットではないことを証明します。 25ユーザーでの1ヶ月試用ができます。 ユーザーへのライセンスの割当て 1ヶ月間のトライアル申し込みはできましたので、テストユーザーにライセンスを割り当てます。 これでテストユーザーにMicrosoft 365 E5のライセンスを割り当てることができました。では次回こそIntuneを構成してデバイス管理の構成をしたいと思います。 シリーズの次の記事はこちら！ Intuneへの登録を行う【M365フルクラウド環境検証 その4】 | Microsoft Cloud Administrators

前回の記事( Windows10をAzure ADに参加させる！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators )ではAADにWin10をAAD Joinさせて、AAD上のIDで直接Win10にサインインができるようにしました。 Win10で直接、職場または学校アカウントでサインイン これはこれで素敵なのですが、AADの規定のドメイン名は「xxxxxxxxx.onmicrosoft.com」という形式であり、ちょっと長いですし、やはり企業用途であれば独自ドメインを使いたいですよね。そうすればユーザーもわかりやすく短いユーザーIDを使ってWin10にログインすることも可能になります。 ということで今回はAADにドメインを追加してユーザーIDを変更してみます。このときに既存のユーザーおよびユーザープロファイル上のファイル等に影響が出るのか、出ないのかも確認します。 現状確認 まず、現状を確認しておきましょう。 初期状態でローカルにユーザーが1つあり、その状態からAADに参加し、AAD上のユーザーで一度サインインした状態のWin10があります。 もちろんローカルユーザーはビルトインのユーザー群と当初に作成した1ユーザーのみであり、AADのユーザーは表示されていません。 ログインしているユーザーはAzure AD上のユーザーです。 環境変数を確認してみます。 C : \ U s e r s \ m e b i s u d a > s e t A L L U S E R S P R O F I L E = C : \ P r o g r a m D a t a A P P D A T A = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ R o a m i n g a s l . l o g = D e s t i n a t i o n = f i l e C o m m o n P r o g r a m F i l e s = C : \ P r o g r a m F i l e s \ C o m m o n F i l e s C o m m o n P r o g r a m F i l e s ( x 8 6 ) = C : \ P r o g r a m F i l e s ( x 8 6 ) \ C o m m o n F i l e s C o m m o n P r o g r a m W 6 4 3 2 = C : \ P r o g r a m F i l e s \ C o m m o n F i l e s C O M P U T E R N A M E = D E S K T O P - 7 J O 0 T J G C o m S p e c = C : \ W I N D O W S \ s y s t e m 3 2 \ c m d . e x e D r i v e r D a t a = C : \ W i n d o w s \ S y s t e m 3 2 \ D r i v e r s \ D r i v e r D a t a F P S _ B R O W S E R _ A P P _ P R O F I L E _ S T R I N G = I n t e r n e t E x p l o r e r F P S _ B R O W S E R _ U S E R _ P R O F I L E _ S T R I N G = D e f a u l t H O M E D R I V E = C : H O M E P A T H = \ U s e r s \ m e b i s u d a L O C A L A P P D A T A = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l L O G O N S E R V E R = \ D E S K T O P - 7 J O 0 T J G N U M B E R _ O F _ P R O C E S S O R S = 4 O n e D r i v e = C : \ U s e r s \ m e b i s u d a \ O n e D r i v e O S = W i n d o w s _ N T P a t h = C : \ P r o g r a m F i l e s ( x 8 6 ) \ C o m m o n F i l e s \ O r a c l e \ J a v a \ j a v a p a t h ; C : \ W I N D O W S \ s y s t e m 3 2 ; C : \ W I N D O W S ; C : \ W I N D O W S \ S y s t e m 3 2 \ W b e m ; C : \ W I N D O W S \ S y s t e m 3 2 \ W i n d o w s P o w e r S h e l l \ v 1 . 0 \ ; C : \ W I N D O W S \ S y s t e m 3 2 \ O p e n S S H \ ; C : \ P r o g r a m F i l e s \ I n t e l \ W i F i \ b i n \ ; C : \ P r o g r a m F i l e s \ C o m m o n F i l e s \ I n t e l \ W i r e l e s s C o m m o n \ ; C : \ P r o g r a m F i l e s \ T o r t o i s e G i t \ b i n ; C : \ P r o g r a m F i l e s \ G i t \ c m d ; C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l \ M i c r o s o f t \ W i n d o w s A p p s P A T H E X T = . C O M ; . E X E ; . B A T ; . C M D ; . V B S ; . V B E ; . J S ; . J S E ; . W S F ; . W S H ; . M S C P R O C E S S O R _ A R C H I T E C T U R E = A M D 6 4 P R O C E S S O R _ I D E N T I F I E R = I n t e l 6 4 F a m i l y 6 M o d e l 6 9 S t e p p i n g 1 , G e n u i n e I n t e l P R O C E S S O R _ L E V E L = 6 P R O C E S S O R _ R E V I S I O N = 4 5 0 1 P r o g r a m D a t a = C : \ P r o g r a m D a t a P r o g r a m F i l e s = C : \ P r o g r a m F i l e s P r o g r a m F i l e s ( x 8 6 ) = C : \ P r o g r a m F i l e s ( x 8 6 ) P r o g r a m W 6 4 3 2 = C : \ P r o g r a m F i l e s P R O M P T = $ P $ G P S M o d u l e P a t h = % P r o g r a m F i l e s % \ W i n d o w s P o w e r S h e l l \ M o d u l e s ; C : \ W I N D O W S \ s y s t e m 3 2 \ W i n d o w s P o w e r S h e l l \ v 1 . 0 \ M o d u l e s P U B L I C = C : \ U s e r s \ P u b l i c S E S S I O N N A M E = C o n s o l e S y s t e m D r i v e = C : S y s t e m R o o t = C : \ W I N D O W S T E M P = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l \ T e m p T M P = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l \ T e m p U S E R D O M A I N = A z u r e A D U S E R D O M A I N _ R O A M I N G P R O F I L E = A z u r e A D U S E R N A M E = m e b i s u d a U S E R P R O F I L E = C : \ U s e r s \ m e b i s u d a w i n d i r = C : \ W I N D O W S きちんとユーザーのドメインはAzureADと表示されていますね。さらに、プロファイルはC:\Users\mebisuda にセットされています。 ...

「もうできるんじゃないか？」「いや、まだ早いんじゃないか？」といつも論争になる(？)完全フルクラウド環境。もうオンプレミスのActive Directoryもファイルサーバーもプリンタサーバーも全部捨てて、フルクラウド環境で問題ないんじゃないか？そのように考えている方も多いと思います。 とはいえ、特にエンタープライズ環境では「いや、まだ無理だろう」という声も大きいですし、実際のところオンプレミスにある膨大な資産をどのように移行していくのか…ということで現実的に考えられない組織も多いと思います。 ですが！ 規模が小さいところで既存資産も対してなく、これから環境を整えたいという状況であればMicrosoft 365をつかってフルクラウドで環境を整えるのは非常に現実的で有力な候補だと思います。というか私がIT環境を全部コントロールできるなら絶対にそうします。 ということで、フルクラウドの検証環境を作って色々と挙動を見ていってみたいとおもいます。シリーズもの的な位置づけになる予定です。 初回はまずAzure ADを新規に用意し、Windows 10をAzure ADに参加させるとから言ってみたいと思います。 dsregcmd /status いきなりコマンドからで恐縮ですが、このコマンドで状況を確認しながら勧めていきたいと思います。 Win10の初期状態にローカルユーザーでログインすると下記のように、Device StateおよびUser StateはすべてNOとなります。 C:\Users\mebisuda>dsregcmd/status +———————————————————————-+ | Device State | +———————————————————————-+ AzureAdJoined : NO EnterpriseJoined : NO DomainJoined : NO +———————————————————————-+ | User State | +———————————————————————-+ NgcSet : NO WorkplaceJoined : NO WamDefaultSet : NO AzureAdPrt : NO AzureAdPrtAuthority : NO EnterprisePrt : NO EnterprisePrtAuthority : NO +———————————————————————-+ | Ngc Prerequisite Check | +———————————————————————-+ IsUserAzureAD : NO PolicyEnabled : NO PostLogonEnabled : YES DeviceEligible : YES SessionIsNotRemote : NO CertEnrollment : none AadRecoveryNeeded : NO PreReqResult : WillNotProvision ...

皆さんこんにちは。胡田です。毎日暑いですね。みなさんお体にお気をつけください。 さて、今回はAzure Portalにアクセスする際の動きをFiddlerで確認してみようと思います。 Azure Portalにアクセスするためには皆さん御存知の通りAzure ADで認証される必要があります。マイクロソフトアカウント利用する場合には「Azure ADで認証」と書いてしまうのは少々正確ではないかもしれませんが、ここでは組織アカウントのみ考えることにします。 このとき、ユーザーとしてはAzure PortalのURL(https://portal.azure.com/)を入力してAzure Portalにアクセスするわけですが、Azure ADで認証する必要があるためリダイレクトされる動きになります。さらに、アクセスしようとしているAzure Subscriptionの紐付いているAzure ADが、ユーザーが存在しているAzure ADとは異なる構成もとれます。このようなときにどのようにブラウザが遷移しているのかをきちんと確認しようというのがこのエントリの趣旨です。 Fiddlerを使うことでHTTP/HTTPSの通信を生で記録、確認することができますので、テストした時点での正確な動きを確認することが可能です。 構成パターンはかなり多数ありますので相当複雑にもなりうるのですが、まずはシンプルなところから何パターンか見ていきたいと思います。 注意：このエントリの内容は「正確さ」に関しては保証しません。自分で実際に試してみて、挙動をみて、考えて、自分の既存の知識や経験、他のドキュメント等と照らし合わせた上で自分の現段階の考えを書いています。ご注意ください。 クラウドIDを使った一番シンプルなパターン まずは下記のような一番シンプルなパターンを見ていきましょう。 AADとしてwindowsadmin.onmicrosoft.comが存在します。 windowsadmin.onmicrosoft.com上にaccesstest@windowsadmin.onmicrosoft.comというアカウントを作成します。このアカウントはクラウド上に存在するアカウントであり、フェデレーション等は構成されていません。 windowsadmin.onmicrosoft.comをディレクトリとして構成された「MVP特典(Visual Studio Ultimate with MSDN)」というAzureサブスクリプションが存在します。 #なんだかひどいサブスクリプション名ですが、管理しているサブスクリプションが大量にあるのできちんと区別しやすい愚直な名前にしております…。 「MVP特典(Visual Studio Ultimate with MSDN)」 上でaccesstest@windowsadmin.onmicrosoftのアカウントに閲覧権限(Reader)を割り当てアクセス可能にしてあります。 実際の挙動 PC上でChromeをシークレットモードで開き、URLにhttps://portal.azure.com/を入力します。 URLがhttps://login.microsoftonline.com/となり認証を求められます。 ユーザー名を入力します。 次にパスワードの入力を求められます。パスワードを入力して「サインイン」をクリックします。 サインインの状態を維持するかどうかを聞かれます。この質問には今後も含めてこの検証内ではすべて「いいえ」で回答します。(テスト目的のため) Azure管理ポータルにアクセスできました。 Fiddlerに記録されたデータを含めた挙動 PC上でChromeをシークレットモードで開き、URLにhttps://portal.azure.com/を入力します。 このときhttps://portal.azure.com/の画面は表示されずすぐに画面が遷移しますがその様子が見て取れます。 1行目ではProxy接続でHTTPSを扱うためにHTTP1.1のCONNECTメソッドが利用されています。 参考URL： Re: Newbie Questions - Google グループ - CONNECT - HTTP | MDN - HTTPSとCONNECTメソッド - ITの窓辺から 2,3行目ではportal.azure.comおよびその配下のJavascriptを取得しています。実際にはJavascriptによってまず認証を行うためのページに遷移させられています。 ...

皆さんこんにちは、胡田です。何やら不穏なタイトルですが私が退職するという話ではありません。関係者の皆さんご安心ください（笑 今回のネタはかなりニッチな話なのですが、私の友人で下記の状況になって困ってしまった人がいました。それを受けてブログエントリを書きました。地味に重要な箇所だと思ってます。 - マイクロソフトアカウントに紐付いていたAzureサブスクリプションを退職前に全て削除したつもりが後日クレジットカードに請求が来てしまった - マイクロソフトアカウントで確認しようとしてももうサインインできなくなってしまった - パスワードリセットなども、もう以前の会社のメールが使えないのでできない この件では結局以前のメールアドレスを復活させる対応が必要となりました。このような事にならないために今回の話は理解しておいてもらえればと思います。 さて今回のお話は前提知識として下記を要求しています。記事を読んでよくわからない部分があった方は参照いただければと思います。 - [個人アカウントと組織アカウント | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e5%80%8b%e4%ba%ba%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%a8%e7%b5%84%e7%b9%94%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88/) 組織のメールには組織を抜けたあとにはアクセスできない さて、会社含めて組織に所属している中で、その組織に紐付いたメールアドレスで各種Webサービスのアカウントを作成することは数多くあることだと思います。マイクロソフト系のクラウド管理者だとかなりの高確率でマイクロソフトアカウントを**『組織のメールアドレスで』**持っていますよね。(※実はこれは現在ではもうできなくなっているのですが、昔からやっている人は持っている人が多いのです。) そして、「組織のメールアドレスがIDである」マイクロソフトアカウントはそもそも作成時に「自分がすでに持っているメールアドレスで作成する」という選択肢を使ってアカウントを作っているので、例えばパスワードを忘れてしまってリセットしたい場合や、新しい場所からサインインした時に追加で確認を求められたりする際には(追加でアカウントに電話番号を追加し、それを利用することもできますが)「組織のメールアドレス」に届くメッセージを使うことになります。 逆に組織の管理者であれば組織内のメールアドレスを自由に作成、削除、変更等できます。これは当たり前ですね。ですから「個人に紐付いているアカウントがたまたま組織のメールアドレスだった」という状況でも、組織の管理者は用意にそのアカウントを乗っ取ってしまうことができます。これってちょっと問題ですよね。なので、組織のメールアドレスで新規にマイクロソフトアカウントを作成することが(過去はできましたが)今は禁止されています。 マイクロソフトアカウントへのメールアドレスの追加方法 「マイクロソフトアカウントでIDとして使っているメールアドレスにアクセスできない」状況ではもう復活の手段がなくなってしまうことは理解いただけたでしょうか？ これを防ぐためには「組織のメールアドレス」にアクセスできているうちに、マイクロソフトアカウントのメールアドレス(これはつまりID自体なのですが)を変更する必要があります。このための機能がきちんと準備されています。 (2019/02/13時点の操作方法　※画面自体はすぐに変更になる可能性が高いです。) https://account.microsoft.com/profile/　にアクセス。 これを編集するためには下記のように追加で本人確認が必要です。ここを突破できるうちにメールアドレスを変更しておくのが肝なんです。 そして、下記のようにメールや電話番号を追加したり、プライマリエイリアスを変更したりなどの操作が行えます。 退職前にはここから個人でいつでもアクセスできるメールアドレスをまず追加し、その追加したメールアドレスをプライマリに変更するのが良いでしょう。さらに、個人でいつでもアクセスできる電話番号も追加しておくことも強くお勧めします。 注意 さて、ここまで書いておいて非常に申し訳ないのですが、実はこの対処を行って「プライマリエイリアス」の変更まで行うと、各種のサービスでおかしなことになる例がありました。私の場合には個人のマイクロソフトアカウントに紐付いているAzure EAポータル上のアカウントおよびそのAzureサブスクリプション周りでおかしな挙動になりました。 あきらかにMicrosoftさん側のバグだと私は思っているのですが…(サポートの方には伝達済み)。そのうち直ることを祈りつつ…。 このあたりの地雷を踏まないようにするためには、「プライマリエイリアスの変更」はそれが絶対に必要な場面において、最悪色々な悪影響が出てしまったとしても大丈夫な状況でのみ行ってください。念の為。 ※私は責任取れませんのであしからず…。 ただ、私自身の個人アカウントは実験も含めて10回くらいプライマリエイリアスの変更を実施して、現在問題なく動いているという事実はありますので、そこまで恐れなくてもいいかも？ 組織の管理者としてはやはり組織アカウントのみを使うべき このような問題も理解すると、より一層、組織としては「組織アカウント」を使うべきであり、「個人アカウント」はあくまでも個人利用のために使うことが望ましいことがわかります。 使えるからと言って、個人アカウントであるマイクロソフトアカウントを組織で契約しているAzure環境の管理者アカウントにしてしまったりするとのちのち面倒なことになります。このブログでも何度も繰り返していることですが、くれぐれもご注意ください。 でも、まだまだマイクロソフトアカウントでの使用例が後を絶たないんですよね…、このブログを見てくれている管理者の方は是非組織アカウントを使っていってもらえればと思います。 関連エントリ 下記のエントリも関連していますので、合わせてごらんいただければと思います。 - [個人アカウントと組織アカウント | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e5%80%8b%e4%ba%ba%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%a8%e7%b5%84%e7%b9%94%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88/) - [クラウド時代のマイクロソフト系インフラ管理者はまずAzure Active Directoryを理解し活用しましょう | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e3%82%af%e3%83%a9%e3%82%a6%e3%83%89%e6%99%82%e4%bb%a3%e3%81%ae%e3%83%9e%e3%82%a4%e3%82%af%e3%83%ad%e3%82%bd%e3%83%95%e3%83%88%e7%b3%bb%e3%82%a4%e3%83%b3%e3%83%95%e3%83%a9%e7%ae%a1%e7%90%86%e8%80%85/) - [アカウントの種類は何を使うべきか？ – チャットでいただいた質問への回答 | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%ae%e7%a8%ae%e9%a1%9e%e3%81%af%e4%bd%95%e3%82%92%e4%bd%bf%e3%81%86%e3%81%b9%e3%81%8d%e3%81%8b%ef%bc%9f-%e3%83%81%e3%83%a3%e3%83%83%e3%83%88/) - [「マイクロソフトアカウントと組織アカウントを変換したい」という質問への回答 | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e3%80%8c%e3%83%9e%e3%82%a4%e3%82%af%e3%83%ad%e3%82%bd%e3%83%95%e3%83%88%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%a8%e7%b5%84%e7%b9%94%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%82%92/)

皆さんこんにちは。胡田です。もう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のサブスクリプションを指しての言葉なのか等、しっかりとその意図するところを確認する必要があるでしょう。 「テナント」という言葉は注意して使いましょう というわけで、今回はなんだか締まらない内容になってしまいました。それだけ曖昧な言葉であるということです。話し手、書き手の意図をきちんと確認し、思い込みで誤解を生まないようにしていただければと思います。

皆さんこんにちは。胡田です。今日は家族で動物園に行ったのですが、複数のヤギにかまってくれとせがまれるおじさんがいてびっくりしました。常連さんでヤギからしっかりと認識されているのでしょうか。…羨ましいです。 さて、このサイトに設置してあるチャットで複数の別の人から「マイクロソフトアカウントと組織アカウントを変換したい」という同じ質問をなんども受けるのでエントリとして公開しておきたいと思います。皆さんだいたい下記のエントリを見たあとに質問してくれています。まず下記が前提知識ということで先に読んでいただけると良いと思います。 - [個人アカウントと組織アカウント | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e5%80%8b%e4%ba%ba%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%a8%e7%b5%84%e7%b9%94%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88/) - [アカウントの種類は何を使うべきか？ – チャットでいただいた質問への回答 | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%ae%e7%a8%ae%e9%a1%9e%e3%81%af%e4%bd%95%e3%82%92%e4%bd%bf%e3%81%86%e3%81%b9%e3%81%8d%e3%81%8b%ef%bc%9f-%e3%83%81%e3%83%a3%e3%83%83%e3%83%88/) さて、この上で「マイクロソフトアカウントに変換できますか？」「組織アカウントに変換できますか？」という質問を受けます。 まず、結論を先に言ってしまうと「変換はできません」という回答になります。残念。 そもそもマイクロソフトアカウントと組織アカウントは完全に別物です。変換できるたぐいのものでもありません。確かに機能的に似ているところがありますし、どちらを使うか？という選択肢がある場面も多いため変換したくなる気持ちもわかりますが…、そもそも論としてあとから変換したくならないようにはじめから「企業であれば組織アカウントを統一的に使う」というのが私のお勧めです。これまでのエントリでも解説したとおりです。 でも、そのうえでこのような回答が多いというのは、話を聞いてみるとどうやら「企業利用だが、よくわからずにマイクロソフトアカウントでつかい初めてしまったけれども、あとから、はじめから組織アカウントを使っておくべきだったことに気がついた」というケースが多いようです。変換自体はできないのですが、設定項目によっては「移行」ができるケースがありますので代表的なところで2つほど紹介しましょう。 Azureの管理アカウントをマイクロソフトアカウントから組織アカウントに変更する Azureには様々な管理アカウントの種類があります。契約によってその管理アカウントの種類も違います。ちょっと種類多すぎですし、きちんと説明しようとすると膨大な説明量になってしまうのでこのエントリでは説明しませんが、「全ての項目に関してマイクロソフトアカウントと組織アカウントの両方が使える」状態に現状はあります。(※昔はマイクロソフトアカウントしか使えなかった時期もありました) ですので、Azure管理に関しては - 組織アカウントを管理者として追加する - マイクロソフトアカウントを管理者から削除する というステップで多くの場所で組織アカウントへの管理に切り替えることができます。変換ではなく切り替えですね。 サブスクリプションのサービスアカウントに関してもマイクロソフトアカウントから組織アカウントへの所有者変更(サブスクリプション転送)も可能です。これを行えば管理上の全ての場所からマイクロソフトアカウントを消すことが可能です。 ただし、この変更にともなってサブスクリプションの規定のディレクトリの変更が発生するケースが大半ですし、それに伴ってサブスクリプションへの管理権限がリセットされる動きとなります。一部のサブスクリプション内のサービスも影響をうけるケースがあります(Azure Automation等)リスクを承知した上であってもおいそれと実施すべきではない作業ではあります。 が、やればできます。 ここは重要なものでなければやってしまってもいいとは思いますが、企業であつかっているような重要なサブスクリプションであればプロにお金をはらって作業をお願いすることをお勧めします。くれぐれもお伝えしたいのはこれはAzureを販売してもらった企業にただでサポートしてもらったり、作業してもらったりするような簡単なものではない(ケースがある)という事です。 イレギュラーなことをすると簡単にAzure上の管理データベース上で不整合が発生しますので注意下さい…。 Windowsのログインアカウント Windowsのログインアカウントとしてマイクロソフトアカウントや組織アカウントが利用できますのでそれを変更したいとお考えの方もいると思います。残念ながらこれは私の知る限り簡単に変更はできないと思っています。 ですが発想を変えてもらうのが良いと思っています。 新規に組織アカウントでそのWindowsにはいれるように構成して、いちから使えばいいんです。ただそれだけです。新しいPCを買ってきてそこでPCをセットアップして新しいアカウントで使い出すのと一緒のことですから。 え?データ移行やアプリケーションのインストールや、各種設定をし直すのが大変ですか? もしもそうであるならば、その事自体が問題であり改善すべきだと私は考えます。 データはクラウドに保持。各種セキュリティポリシーもWindowsの設定もクラウド上で構成され、同一IDに対しては自動適用される。アプリケーションも自動的に展開される。こういう環境にしてしまえば、特になにも恐れることは無いですよね。 そもそもPCなんていつ壊れるかもわかりませんし、複数のPCで作業することだってあるでしょうし、スマフォでだって作業するでしょうし、マルウェアにやられて初期化しなくちゃいけなくなることだってありえますし、Windows Updateが失敗するかもしれないし、いつでも簡単にリセット可能な状況にしておくことが重要だし、結果的に生産性が高まると私は考えるのです。 まとめ というわけで、まとめとしては - マイクロソフトアカウントと組織アカウントは「変換」はできない - 「変換」はできないがアカウント権限付け替え等をして組織アカウントに「移行」することはできるケースが多い - Azureサブスクリプションのサービス管理者だけは要注意 - Windowsはアカウントの変換とか考えないでクラウドを活用してそもそも気軽に初期化可能にしてしまいましょう ということになります。 参考になるところがあれば幸いです。 引き続き右下のチャットより質問や「いやそういうことじゃなくてね・・・」という情報をお待ちしております。

最近あるAzure Subscriptionに対して個別のユーザーに個別のRGのみ作成して権限を割り当てるということを都度都度行う必要が出てきました。 海よりも深い事情があり、普段利用している組織アカウントにはAzureサブスクリプションを紐付けられない理由があり(EA契約に紐付いているのでEA契約にコンバートされてしまう)、仕方なく別AADに紐づけて作成してあります。 でも、Azure環境は普段利用している組織アカウントを限定的な権限および範囲で使ってほしいため…以下のような作業をすることにしました。 - Azure AD B2Bで別のAADの組織ユーザーを招待する - 招待したユーザー用にリソースグループを1つ作成する - 作成したリソースグループに招待したユーザーを共同作成者としてアサインする 手作業だとちょっと時間かかりすぎるのと、繰り返し何人も都度都度対応する必要があるので、PowerShellスクリプトを書きました。 - [https://github.com/ebibibi/AzureManagement/blob/master/AAD/InviteUserWithAADB2B.ps1](https://github.com/ebibibi/AzureManagement/blob/master/AAD/InviteUserWithAADB2B.ps1) 外部テナントのユーザーを招待した直後に権限を割り当てて大丈夫なのかちょっと不安でしたが、どうやら意図したとおりにうまく動いているようです。

ASDKを毎月デプロイしていると、AADの中にAzure Stackのアプリケーションが沢山できてしまいます。最新のものを残して古いものを削除する為のスクリプトが無保証で参考に公開されていましたので、共有します。 - [AzureManagement/CleanAzureStackAADApps.ps1 at master · ebibibi/AzureManagement](https://github.com/ebibibi/AzureManagement/blob/master/AzureStack/CleanAzureStackAADApps/CleanAzureStackAADApps.ps1)

マイクロソフトのクラウドサービスを利用しようとしたり、クラウドプラットフォーム上でIDを作成、管理しようとしたり、Windows 10をセットアップしようとしたときにまず1番最初に混乱するのが「個人アカウント」と「組織アカウント」の違いだと思います。両方の種類のIDが使えるサービス、片方のIDしか使えないサービス、両方のIDが使えるんだけど、実は領域が別れているサービスなど、多種多様な状況です。私自身かなり長期間に渡って苦しめられてきたというのが正直な所です。 少々技術的に細かい話にもなってしまいますが、しっかりと説明してみたいと思います。 なお、私個人のおすすめは「使える所は全て組織アカウントで統一する」です。 (2021/09/29追記)動画で改めて解説しました YouTube の動画にて改めてこのテーマをまた別の角度から解説しました。ブログ記事と合わせてご覧ください。 https://youtu.be/s1Rm7M2tMAg (2021/09/19追記)Windows 11, Windows 10の両方をカバーし、さらに管理者側の話にも踏み込んだYouTube動画を作成しました本エントリは解説の角度が違いますので、両方見ていただくとより理解が深まります。是非動画も本エントリも両方ご覧いただければと思います。 https://youtu.be/zC5n5S6wfH8 **(2019/06/30追記)**Windows 10の初期セットアップで「個人用に設定」「組織用に設定」のどちらを選択したらいいのか？このページから「Windows 10の初期セットアップで「個人用に設定」「組織用に設定」のどちらを選択したらいいのか？」という質問があまりにも大量に寄せられるので、Windows 10の初期セットアップに特化した解説動画を作成しました。 Windows 10の初期セットアップにお困りの方は下記動画をご覧いただければと思います。 ※動画を見ていただければ初期セットアップは完了できると思います。あとでこのエントリの残りの文章も読んでいただけるとより深く理解いただけると思います。 (2020/02/19追記)Windows 10再インストール手順このページを見たから「『個人用に設定』と『組織用に設定』を間違って設定してしまったがあとから変更できますか？」という質問を数十回単位で質問頂いています。色々とやり方はあるのですが、基本的に「データをすべてクラウドに置いておいた上でWindows 10を再インストールしてしまう」という方法が非常におすすめです。その方法を動画で解説しましたので、是非御覧ください。 歴史的経緯まず最初にこの話には歴史的経緯があるのだということを認識しておくのがおすすめです。そして、特に「Azure」関連で度々の仕様変更があり、それが複雑さに拍車をかけています。具体的には当初、「個人アカウント」でしかAzureの管理ができない時代がありました。 ですが、その後、Office 365の普及=Azure ADの普及=「組織アカウント」の普及に伴って、Azureの管理がどんどん「個人アカウント」ではなく、「組織アカウント」で行うべきものに変化してきました。 この影響を受けて個人アカウントと組織アカウントの混在や、役割の変化、ドキュメントによって言っていることが違う…等の混乱を生むことになった…というのが私の理解です。 ですので、過去のドキュメントを見る時にはこのあたりも注意してもらうのが良いと思います。 注意：このあたり人によっては全く違う見解、意見を持っているかとは思います。石を投げないで下さい。 個人アカウント＝マイクロソフトアカウント 組織アカウント=Azure Active Directoryのアカウント=Office 365のアカウントまず一番最初に理解すべきことは、個人アカウントが「マイクロソフトアカウント」であり、組織アカウントは「Azure Active Directoryのアカウント(=Office 365のアカウント)」であるということです。それぞれは「誰が管理者なのか」という点で明確に大きな違いがあります。 「個人アカウント=マイクロソフトアカウント」は個人が勝手に作成できるマイクロソフトアカウントは以下のURLから作成できるアカウントです。 - [https://signup.live.com/](https://signup.live.com/) 無料で作成できるにもかかわらずメールアドレスを取得し、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上のユーザーアカウントも分類するなら個人アカウントではなく、組織アカウントと考えられますね。 こちらも最大のポイントは「管理者が作成、管理するものであり、個人では勝手に作成できない組織のためのアカウント」という所です。 Windows 10も進化が進み、新しいバージョンでは直接組織アカウントを使ってWindows 10にログインすることができるようになっています。 組織アカウントはマイクロソフトのクラウドサービスを組織で利用する時に必要となる組織アカウントはマイクロソフトのクラウドサービスを組織で利用する時に必要となります。実はマイクロソフトのクラウドサービスの出始めのころは「組織アカウント」という呼び方も「Azure Active Directory」もほぼ説明されていませんでした。 Office 365の前身のBPOSというクラウドサービスのときには単にBPOSに対してIDを作成する、IDを同期するという概念だったと記憶しています。(※昔のことなので記憶違いかもしれません。) ...

オンプレミスの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を利用して全てのものを利用可能とするのが最も便利でセキュアで運用コストが低いから」です。この点はもっと説明が必要ですのでまた今後のブログエントリで解説していきたいと思います。

このあたり追いかけていない人には何のことかわからないと思いますが、個人的に衝撃だったので簡単にブログにポストします。 - マイクロソフトアカウントを作成すると、そのユーザー名とメールドメインに紐付いて自動的にAADテナントが作成されるようになっていました！ - しかも、そのAADテナントには**マイクロソフトアカウントに紐づけたメールアドレスがユーザー名である組織アカウント**が自動作成されています！ 上記がその証拠画像です。 いつからこうなってたんでしょうか？マイクロソフトアカウントを作成するときにAADにすでに登録済みのドメインのメールアドレスは使えないようになったのはずいぶん前ですが、この条件であればこうできるのかな？という感じではありますが。 マイクロソフトアカウントはAzureからみると以前はAADには紐付かない宙ぶらりんなアカウントでしたが、今はAzure利用という観点でみるとしっかりとAADにも紐づく存在になってきているようです。 もっとも、新規作成のマイクロソフトアカウントはこの状態だとしても、以前から存在しているマイクロソフトアカウントはまた違うようですが。 それにしても、AADに追加した確認済みのドメイン名ではないドメインの組織アカウントがディレクトリ内に存在する状態にしてしまって、ほかとの整合性は大丈夫なんでしょうか？ちょっと心配な部分もありますが、うまくさばいてくれることを期待しながら…。 なお、このようにマイクロソフトアカウントもAADに紐付いたので、サブスクリプション転送時にもディレクトリの切り替えが発生するパターンが増えていますね。このあたり諸々注意が必要です。 個人的にはもうマイクロソフトアカウントも全部完全にAADのアカウントです、という形で整理してくれた方がスッキリする気がしますが…。

過去から何度も言われていることですが、パスワードは無期限に設定したほうがセキュリティ対策上好ましいです。(反対派も根強く存在しますが) 先日、Office 365の管理者画面に久しぶりにアクセスしたところ、推奨事項として簡単にパスワードを無期限に設定できるようになっていました。感動してTwitterに投稿した所、3000回近くリツイート、お気に入り登録がなされました。 マイクロソフトがついにパスワード無期限を推奨事項としてO365の管理画面に出してくれた！！素晴らしい！！！ pic.twitter.com/GqRNv7uOqu — Masahiko Ebisuda (@ebi) 2018年2月27日 個人的には過去最高のTwitter上での反応でした。それだけパスワードの定期変更が設定され、それに不満を持っている人が多いということなのだと思います。 ただ、画像のメッセージ上では「ユーザーアカウントをクラウドで管理している場合は、パスワードを無期限に設定することをお勧めします。」という表現になっています。 「これを推奨する理由の詳細を表示」のリンク先は下記のアドレスをなっており、そこではオンプレミス、クラウドにかかわらずパスワードの定期変更は良くないこととして解説されています。 - [Password Guidance - Microsoft Research](https://www.microsoft.com/en-us/research/publication/password-guidance/) それでも、あえてOffice 365上の管理画面にて「クラウドで管理している場合は」という書き方をしているのかと言うと・・・、そこにはAzure Active Direcotryが備えているセキュリティ対策機能の存在があるからだろうと思いますし、ADFSを使わずにAzure Active Directory上でユーザー認証を可能な状態にしてほしいという思想が表現されていると思います。 以下は私の推測や考えも混じっていますので全部そのままうのみにはしないでいただきたいのですが… まず、Azure Active Directoryの開発者はクラウド上でユーザーを管理する事、つまりパスワードハッシュもAzure Active Directory上まで同期する構成を強く推奨しています。（これは本当です。直接聞いてます。） そうすることによって、脆弱なパスワードを設定しているユーザーは一発で判別できますし、怪しい挙動をしているユーザーをAzure Active Directory側で検知できます。 オンプレミスのActive Directoryで適当な管理をしている状態よりもAzure Active Directory上で管理したほうが遥かにセキュアにできるんです。 わたしはこれは自明なことだと思います。だって、Azure Active Directoryからユーザーデータベースを引っこ抜くのと、オンプレミスのActive Directoryからデータベースを引っこ抜くなり、DCのイメージを盗み出すなりするのと、どちらが簡単でしょうか？圧倒的に後者の方が簡単ですよね。というか、前者はできる気がしないです。 よく「クラウドにパスワードを置くのはセキュリティ的に危ない。だからADFSをつかってオンプレミスにパスワードを置く。」という言い方をする人がいますよね。これ、二重の意味で間違っています。 まず、そもそもパスワードってどこにも置かれていません。パスワードがそのまま生で暗号化もハッシュ化もされずに置かれているなんてとんでもなく間違った設計です。危険なんてもんじゃなく、ひどすぎます。 たしかに、「パスワードを忘れた」ボタンをおしたらメールで生のパスワードを教えてくれるWebサービスは存在します。残念ながら。ですが、それはあまりにもひどすぎる実装なのであって、そもそもそんなサービスをつかってはいけないと言っても過言じゃないくらいのひどい実装です。(だから、パスワードは全部違うものにしましょうね。) パスワードはそのまま生で保存しては大変に危険なので、そのままは保存しないのが鉄則なんです。パスワードを生で保存しなくても正しいパスワードを入力したことを調べる術というのはきちんと存在していて、パスワードのハッシュ値を保存しておき、ユーザー認証時のパスワード入力に関してもそのハッシュ値を比較し、同一であれば正しいパスワードが入力されたということが判断できます。あるいはそもそもパスワードを必要としない実装にする方法もありますね。 なので、そもそも「パスワード」そのものはどこにも置かれていないのです。頭の中にあるだけです。その辺の紙に書かないでくださいね。(パスワード管理ソフトに可逆変換状態で保存されるのはありだと思います。) そして、ADFSを使ってオンプレミスのADで認証を行った場合は、セキュリティ的にAzure Active Direcotryで認証させるよりもセキュリティ的に強固であるという主張の根拠が私には全くわからないです。 たとえば、外部からのアクセスは全部ブロックしてるんです…というのでも、それAzure Active Directoryでもできますしね。マイクロソフトが物凄い数の世界中の組織のIDを束ねて超厳格に管理してくれているAzure Active Directoryと、自前で構築しているADFS + Active Directoryとを比較して「うちの組織の認証システムはMicrosoftよりもイケてる！」と言えるって凄い自信だなと思います。これって製品コードだけではなくて、運用面等まですべて含めての話ですからね。 それで、Azure Active Directoryを前提とした時に「パスワードは無期限に設定したほうがよい」というのは真だと思います。 オンプレミスのADFS + Active Directoryに関しては「やられてるんだけど気がついてません。」という状況の時にパスワード変更を行ってその結果、セキュリティ対策的に意味があるものになる…という可能性は無いことは無い(そもそも前提からおかしいんだけど)という感じには思うわけです。 そもそもは、パスワードを十分に長くて複雑なものにしておけば良いわけです。そして、その上でパスワードが盗まれても大丈夫なように多要素認証にもしておくべきです。さらにさらに、ユーザーの挙動をみて、怪しいものはブロックもできるようにしておけばさらに安心ですし、ルールを守れず脆弱なパスワードを付けてしまう人も一定数いるでしょうからそれは設定できないようにブロックしたり、設定されてしまっているものは洗い出せるようにすべきです。冗長化、負荷分散もしっかりとしていないといけませんね。インターネットに公開されている認証の窓口なので、攻撃も沢山くるでしょう、それも検知してブロックしなければですね。DDos攻撃だってくるでしょう、それも対処可能でなければいけません。Azure Active Directory(+ Premium P1, P2)ならこれ全部やってくれます。この前提の中では当たり前にパスワードは無期限にして、ユーザーに正しく複雑なパスワードを設定してもらうのが良いですね。 ...

日経SYSTEMSの2017年9月号のAzure Stackに関連する記事に私のコメントも掲載されています。 日本ビジネスシステムズの胡田氏は「Azure StackでID管理に用いるAzure Active Directoryは、ユーザー企業のオンプレミス環境で一般的なActive Directoryとは別物。混乱を招く恐れがある」と指摘する。私も、Web上や雑誌上でも記事を書いたり、インタビューを受けてコメントが掲載されたりなどかなり露出がふえており、大変ありがたいことです。私は人生の生存戦略において、外部露出を増やす戦略でやっていますので実名でこのように雑誌記事にコメントがのるのは大変ありがたいことでして、是非インタビューでもなんでもお声がけいただければと思います。 と、大変ありがたい話ではあるのですが、流石に短い紙面でこのコメントだけ掲載だと相当の誤解を産んでしまうのも致し方がないところだと思います。このコメントに関しては追加で補足をさせてもらおうと思います。 まず、Azure StackでID管理にAzure Active Directoryを用いるというのは半分正しく、半分正しくありません。Azure Stack自体へのアクセス、特に管理ポータルへのアクセス時に使うIDはAzure Active DirectoryとADFSのどちらかが選択可能です。推奨はAzure Active Directoryであり、つまりはクラウド上のIDですからインターネット接続が行えることが前提条件となります。Azure Active DirectoryのIDということはつまりはO365で利用しているIDとも共通とすることができるわけであり、Microsoftの戦略からするとクラウドIDの中心としてのAzure Active Directoryを軸に全てのクラウドサービスをコントロールしようとしていますので、Azure Stackもその1つということで何も違和感がありません。 ただ、一方で「インターネットには接続させない、クラウドサービスは利用できない」という環境ではAzure Active Directoryを使うことはできませんから、そのためのオプションとしてADFSおよびADFSと連携するActive DirectoryをIDとすることもAzure Stackでは可能となっています。この場合、「ユーザー企業のオンプレミス環境で一般的なActive Directory」のIDをそのまま利用可能となりますから、何も混乱なく利用可能となります。 さらにいうと、企業においてAzure Active Directoryを利用する場合にはそのIDはオンプレミスのActive DirectoryとAD Syncにて同期されているケースが非常員多いため、Azure Active DirectoryをIDとしている場合でも、それは事実上Active DirectoryのIDと統一であり、混乱を招くようなものではないケースが多いでしょう。 記事上では表現されていませんが、私が危惧している心配はAzure Stackのマネジメントポータル利用時のIDではなく、Azure Stack上に構築されるシステムへのアクセスに利用されるIDに関してなのです。 もちろんAzure Stack上にIaaSを利用してWindows Serverを展開し、そのWindows Serverを既存のネットワーク上のActive Directoryにドメイン参加させ、いつもと同じようにAD統合認証でシステムを作成する…、これはもちろんやろうと思えばできるのですが、これをやろうと思うと、オンプレミス同士にもかかわらずVPN接続が必要になってきます。これ、非常に違和感が出てしまうんじゃないかと思っています。 もちろんAzure StackはAzureそのものなのですから、VPNで接続するというのはAzureと同等であり、一貫性があります。 でも、同じ社内ネットワークに存在している「隣のサーバー」なのにVPNをはらないとネットワーク的につながらないというのはちょっと違和感を感じるひとが多いいんじゃないかと思うんです。 さらにAzure StackになるとInfrastructure as Codeも非常にやりやすくなります。コードにシステムを表現しておいて、それを展開して環境を作り出す…必要なくなったら消す…そんなことをバンバンするようになってくると…。既存環境へのVPN接続やドメイン参加をして…ということが非常に足かせになってしまいます。そもそも同じ環境を2つ作ろうとおもうと、コンピューターアカウントが重複して問題が発生してしまったりもしますしね。 つまり、Azure Stack上でAzure Stackらしい使い方をしようと思うと、今までのようにActive Directoryを使った認証にするのではなく、自然とAzure Active Directoryを使った認証システムを採用することになると思っています。 Azure Active Directoryに寄せることで色々とメリットも出てきます。Azure Active Directory Premiumの各種機能を使って認証を強化したり、セキュリティを強化したりできるが大きいでしょうか。 このあたりをきちんと理解してシステムを組んでいくようになるのがすぐ近い未来だと私は思っています。「社内であっても認証にActive DirectoryではなくAzure Active Directoryを使う」このあたりをきちんと理解し、システムを構築するようになるまでには、まだまだ結構色々とあちこちで苦労があるだろうなと思ってます。 雑誌のコメントにはこのようなバックグラウンドがあり、それが凝縮されてあのような表現になっているわけです。 Azure Stackを利用するなら、IaaSでVPNをつかって既存のシステムとネットワーク的にに連携してAD統合認証…ではなく、PaaSをつかって認証はAzure Active Directoryを使ったシステムをまず第一に考えて行きたいですね！ ...

皆さんこんにちは。胡田です。 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です。 ...