Azure AD

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

前回の記事( 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 にセットされています。 ...

皆さんこんにちは、胡田です。何やら不穏なタイトルですが私が退職するという話ではありません。関係者の皆さんご安心ください（笑 今回のネタはかなりニッチな話なのですが、私の友人で下記の状況になって困ってしまった人がいました。それを受けてブログエントリを書きました。地味に重要な箇所だと思ってます。 - マイクロソフトアカウントに紐付いていた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/)

最近ある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)

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

卒業式シーズン真っ只中、今週のトピックスです。 - 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 ...

春は三寒四温というように陽気が不安定です。どうか無理なさらず。 さて、今週のトピックスです。 - Azure AD Connect のシングル サインオン & パススルー認証 (プレビュー) によるクラウド完結のユーザー認証インフラの実現 – MS Japan Office 365 Tech Blog 2 users こんにちは、プロダクティビティ担当の和田です。 必要なのはわかってはいるのですが、AD FS サーバーの運用って、大変ですよね？ ユーザーにシングル サインオン環境は提供したいが、せっかくクラウドを使用するのに、新規サーバーを構築して、かつ公的証明書などを含むサーバ… [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, azuread どんどんこっちの方向でいきたいですね。 55 clicks 2 RT リンク2017/03/08 - ニュース - そのファームウエア更新待った、ヤマハ製ルーターが起動しなくなる不具合：ITpro 2 users ヤマハは2017年3月6日、同社のルーター「RTX1210」の一部で、ファームウエアを更新すると起動しなくなる不具合を発表した。最新のファームウエア（リビジョン14.01.16）は2月10日まで提供されていた。 ファームウエアを更新すると不具合が起こるRTX1210… ...

Azureサブスクリプションには「既定のディレクトリ」という概念があり、紐付いているAzure Active Directoryのユーザーを管理に使用することが出来ます。企業で利用する場合にはAzureの管理にマイクロソフトアカウントではなく、組織アカウントを使用することがセキュリティの観点から良いと思います。アカウント生成、削除、多要素認証の適用等適切に管理可能だからです。 以下では新規のAzureサブスクリプションに対してすでに存在しておりO365で使用しているAzure Active Directoryを既定のディレクトリとして紐付ける方法を紹介します。 まず、Azure管理ポータルにアクセスします。2016/04/07時点ではまだAzure Active Directory周りの管理操作はクラシックポータル上で行う必要があります。 https://manage.windowsazure.com/ 左ペインから「Active Directory」を選択した所です。サブスクリプション作成時に自動的に生成された「Default Directory」(※「規定のディレクトリ」の場合が多いと思います。)のみが見える状態になっています。 「設定」にて確認をするとサブスクリプションに対して、規定のディレクトリが紐付いていることが確認出来ます。 この規定のディレクトリを変更していきますが、変更するためには変更先のAzure Active Directoryの管理者として現在操作しているアカウントが権限をもっていなければいけません。別途O365の管理コンソールから操作することも可能ですし、場合によってはだれか別の人に管理者に追加してもらう必要がある場合もあるでしょう。 ここではひとつのやり方として、O365の全体管理者のアカウント(Azureの管理者とは別のアカウント)を自分自身が持っている前提で、Azure管理ポータル上の操作で権限追加まで行う方法を紹介します。 この場合まずAzure管理ポータル上のActive Directoryの一覧に、紐付ける先のAzure Active Directoryが表示される状態にします(これは必須ではありませんが一つのわかりやすいやり方です)。 このため、まず、O365で使用しているAzure Active Directoryへの接続を行います。 「Active Directory」にて「新規」をクリックします。 「ディレクトリ」をクリックします。 「カスタム作成」をクリックします。 「既存のディレクトリの使用」を選択します。 「 既存のディレクトリを使用するには、その前にユーザーがサインアウトし、ディレクトリの全体管理者としてもう一度サインインする必要があります。」と表示されます。 ここで混乱してしまう人が多いのですが、つまりこれはまず事前にアクセス権を付与するための操作です。 これからAzure管理ポータルにAzure Active Direcotryを追加してそれを管理しようとしていますが、そのためには、そのAzure Active Directory自体の全体管理者の権限が必要です。全体管理者の権限を付与するためには、その権限をすでに持っているアカウントで操作する必要があります。ですから、一度サインアウトして、別のアカウントで(この場合はO365の全体管理者で)サインインしなさいと言われているわけです。 チェックをつけて、次に進みます。 サインアウトされます。 サインイン画面になります。 ここではO365の全体管理者の権限を持つアカウントでサインインします。 サインインします。 権限付与する旨のメッセージが出ます。続行します。 権限が付与されました。サインアウトします。 Azureの管理者アカウントでサインインします。 O365で利用しているAzure Active Directoryが新しく追加されました。 これでAzureサブスクリプションの規定のディレクトリを変更する準備が整いました。 これからAzureサブスクリプションの規定のディレクトリを「Default Directory」から「ebisuda」に変更します。 「設定」に移動し、規定のディレクトリを変更する対象のサブスクリプションを選択した上で「ディレクトリの編集」をクリックします。 ...

一つ前の投稿でAzureサブスクリプションとAzure Active Directory(以下AAD)まわりで苦労した話を書いたばかりですが、やはりこのあたりで苦労している人は多いらしく、質問がきましたのでせっかくなのでブログで回答してみたいと思います。スクリーンショットもペタペタしながらですね。 Q1. 組織アカウントでサブスクリプションの共同管理者としてポータルを操作する方法 →サービス管理者の権限でどうやったら設定できるのか教えてください 質問はサービス管理者はマイクロソフトアカウントで現状使っているのだけれども、それを組織アカウントに権限を付与し、そのアカウントでAzureポータルを操作したい…ということだと理解しました。 この場合にはユーザーを作成してそこに権限を出してあげればよいです。操作手順…を見る前に1つだけ注意です。Azureサブスクリプションの共同管理者として追加できるのはAzureサブスクリプションの規定のディレクトリのユーザーのみです。ですので、まず最初におこなうことは「どのディレクトリの組織アカウントを共同管理者にすべきなのか」です。特にO365を利用しており、「組織アカウント」が暗黙的にこのO365が参照しているAADディレクトリである場合には、それを規定のディレクトリにまずする必要があります。 質問から早速脱線してしまいますが、先に、現在Azureコンソール上に表示されていないAADディレクトリに接続する方法を紹介しておきます。 まず、サービス管理者でAzureポータルにアクセスします。まだ現在ではクラシックポータルでの操作となります。 まず、Active Directoryを選択します。私の環境ではすでに複数作成および接続済みですが通常ははじめは「規定のディレクトリ」のみが表示されていると思います。 新規からカスタム作成をします。 既存のディレクトリに接続したくても、ここで選択するのは「カスタム作成」です。エントリの作成くらいの意味なんでしょうね。きっと。 ここで、「既存のディレクトリの使用」を選択します。これによって、すでに存在しているディレクトリに接続するわけですね。 このあとの操作ははじめは戸惑うところだとおもいますが、いちどサインアウトして、「ディレクトリの全体管理者として」サインインします。 ここ、ポイントです。 今、AzureポータルにはAzureサブスクリプションの管理者としてアクセスしています。そして次は、Azure Active Directoryディレクトリの全体管理者としてサインインするのです。 つまり、 「Azureサブスクリプションの管理者」と「Azure Active Directoryの管理者」は全くの別物 であり Azure Active Directory内に「Azureサブスクリプションの管理者」に対しての権限を追加し、参照可能とする 操作をこれからしようという画面なわけです。 あとは、単純にウィザード通り進めればよいので省略します…すいません。入るアカウントを間違えないように！ …というわけで、目的のAADディレクトリが接続できたら、次はそのAADディレクトリをAzureサブスクリプションの規定のAADディレクトリとして設定します。 「設定」の項目で「ディレクトリの編集」をクリックします。 ここで、変更可能なディレクトリ一覧(管理ポータル上で接続しているもの)がでてきますので、目的のものを選択してあとは進めていけばOKです。 さて、これでAzureサブスクリプションには目的のAADディレクトリが紐付いているはずですので、そこにユーザーを作成し、それを共同管理者にしていきます。 (ここからが質問への回答) 目的のAADディレクトリを選択します。 ユーザーの追加をクリックします。 組織内の新しいユーザーを作成します。(これが組織アカウントです。) ここに「ロール」がありますが、ここも注意！これはAADディレクトリに対してのロールであり、Azureサブスクリプションのことは何も言っていません。両者は別物です！ あとは一時パスワードの生成等進めていくだけです。 これでソースが「Microsoft Azure Active Directory」のユーザーができました。これが組織アカウントです。 このアカウントをこのAzureサブスクリプションの共同管理者に追加していきましょう！ 「設定」にて「管理者」を選択し、「追加」を行います。 これでnewadmin@windowsadmin.onmicrosoft.comが共同管理者となりました。 サインアウトし、このアカウントで入り直してみます。 はい。これで組織アカウントで共同管理者としてAzureポータルにアクセスできました。 右上のアイコンがきちんと組織アカウントのものになっています。 ...

前回のエントリに引き続き、AzureサブスクリプションとAAD周りの質問への回答です。 Q. 共同管理者権限のMSアカウントをAADの既定ディレクトリと紐付ける方法 → サブスクリプションに紐付いた既定のディレクトリを共同管理者にも操作させたいんですが、どうやったらいいのか教えてください これは、前回の内容が理解できればもう答えが出ている内容ですね。(エントリわけなくてよかったですな・・・） AzureサブスクリプションとAADディレクトリの権限はべつなので、該当のMSアカウントをAADの管理者にしつつ、コンソール上でAADに接続してしまえばよいです。 これはまさに前回のエントリで既存のディレクトリへの接続を行った操作を行えばよいです。 AADはAzureサブスクリプションとは完全に独立して別途存在しているものなので、両者をべつものとして考え、見る、操作させるためには権限が必要と考え…としていくと理解は容易かなと思います。このあたりADのころの信頼関係を結ぶあたりと似てますね。複雑で混乱しやすいあたりも…。

“Identity is the new control plane” これがMicrosoftのモバイル戦略の最新のキーワードです。 Azure AD, Microsoft Intune and Windows 10 – Using the cloud to modernize enterprise mobility! - Active Directory Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/ad/archive/2015/06/12/azure-ad-microsoft-intune-and-windows-10-using-the-cloud-to-modernize-enterprise-mobility.aspx 上記のブログが非常に「濃い」内容だったので、自分の考えの整理も兼ねて内容のサマリーを…。 Windows 10デバイス(スマートフォン、タブレット、PC等)がAzure ADに参加すると自動的に会社のポリシーに従ってMDMに登録される。会社のデバイスでも、個人のデバイスでも。 - 以下の要素に基づいたポリシーベースのアクセスコントロールでリソースを保護する O365等のアプリケーション - デバイスのヘルスやコンプライアンス状態 - ユーザーのプロファイル、属性、グループ - 認証強度 - アクセス元の場所 - クラウドのアプリケーションとオンプレミスのアプリケーションとの両方に、同一のポリシーでのアクセスコントロールを可能にする - これら全てをクラウドで実現する。新しいサーバーもネットワークデバイスも不必要。VPNも不必要。ほんの数時間で実現できる。 マイクロソフトは個人デバイスの持ち込みであっても、会社のデバイスであってもきちんと自動的にコントロール可能となるシナリオを重視していることがよくわかります。ECSライセンスだと個人のデバイスにOSの実行権限もOfficeの実行権限もつきますしね。 「会社のデバイスのみを会社のデータにアクセスさせる(≒以下に個人所有のデバイスのアクセスをブロックできるか)」というポリシーの企業も特に日本では多いと感じていますが、BYODによって個人にも会社にもメリットを出そうという考え方は合理的だと個人的に思います。 この大きな方向性の中で、会社のデータをいかに個人に不便を与えることなく安全に守るか。これをOSとクラウドで実現しようというわけですね。さすがはOSまで作っているマイクロソフト…といったところでしょうか。(もちろんWindows10以外のOSへの対応も進むものと思われますが!) AzureAD(premium)にて柔軟なポリシー設定ができないのがいままで色々とネックとなりADFS含めて他のソリューションが色々と必要な状況がありましたが、ついにMicrosoftのクラウドサービスだけで完結できるようになりますね。 軸足がどんどんオンプレミスからクラウド側にうつすことが「可能」になってきています。そしてWindows10においてはモバイルデバイスとPCとの境目は全くなくなる事になります。まさにモバイルファースト、クラウドファーストという感じですね。 Windows10ではOSのセットアップ時にAzure ADに参加が非常に簡単にできます。 個人利用のWindows10も簡単にAzure ADに参加できます。 管理者がIntuneにデバイスの管理ポリシーを設定し、Azure ADに条件に基づいたアクセスコントロールポリシーを設定します。 Intuneはデバイスがきちんとコンプライアンス設定が満たされているかを評価し、その結果をAzure ADにレポートします。 この時、きちんと「デバイス」とそれを使用している「ユーザー」が紐づくのが大きなポイントですね。 ...