Microsoft Cloud

皆さんこんにちは。胡田です。今日は家族で動物園に行ったのですが、複数のヤギにかまってくれとせがまれるおじさんがいてびっくりしました。常連さんでヤギからしっかりと認識されているのでしょうか。…羨ましいです。 さて、このサイトに設置してあるチャットで複数の別の人から「マイクロソフトアカウントと組織アカウントを変換したい」という同じ質問をなんども受けるのでエントリとして公開しておきたいと思います。皆さんだいたい下記のエントリを見たあとに質問してくれています。まず下記が前提知識ということで先に読んでいただけると良いと思います。 - [個人アカウントと組織アカウント | 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はアカウントの変換とか考えないでクラウドを活用してそもそも気軽に初期化可能にしてしまいましょう ということになります。 参考になるところがあれば幸いです。 引き続き右下のチャットより質問や「いやそういうことじゃなくてね・・・」という情報をお待ちしております。

継続的にチャットにて質問をいただいております。結構会話が弾むこともありなかなか楽しいです。 私には会話相手が誰だかわからない状態から会話が始まり、継続的にフォローを希望する方はメールアドレスを登録してもらう事でIDの認証と継続的に同じスレッドで会話ができるようになる仕組みです。メールは一時的に取得したフリーのアドレスでも大丈夫です。 よければお気軽にお声がけ下さいませ！ Q. これからAzureを導入しようとしている。Windows10クライアントも利用している。アカウントは何を使うべきか？ 特に、個人アカウント(マイクロソフトアカウント)と組織アカウント(Azure Active Directoryのアカウント)のどちらを使うべきか、という観点での質問をいただきました。 前提としては下記ブログエントリを読んでいただくとして… - [個人アカウントと組織アカウント](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/) まず、明確にOffice 365を利用するなら組織アカウントを使うようになるのは仕様です。そして、Azureの管理に関しては全て組織アカウントを使うようにするのが超おすすめです。 つまり、Office 365で使うアカウントで、Azureの管理も行えるようにするという事です。 さらに、自社で作成するアプリケーションも、その他のSaaSも全て同じアカウントでの利用をお勧めします。これは以下で述べたことと同じです。 - [クラウド時代のマイクロソフト系インフラ管理者はまず](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/)[Azure Active Directory](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/)[を理解し活用しましょう](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/) ここまではいいのですが、Windows 10にログインするときのアカウントをどうするかはちょっと私でも思案します。 選択肢としては大きく以下があります。 - ローカルアカウント - Active Directory のドメインアカウント - 個人アカウント(マイクロソフトアカウント) - 組織アカウント 自宅で使う個人のPCなら3で良いでしょう。1は特に使わなくていいと思います。 企業で使うPCの場合、多いのはそもそも今まで2で運用していたのでそのまま2というケースが圧倒的に多いと思います。これはこれで現実的ですし、Active Directory のアカウントとAzure Active Directory のアカウントを同期し、スムーズに認証連携させる方法も複数あるので問題ありません。 むしろ現実的にオンプレミスに既存のAD統合認証で利用するさまざまなシステムがあればこうならざるを得ません。 そして、これから新規に環境を整えていく段階の組織であれば4を選択してフルクラウドの環境にしてしまうことをお勧めしますし、それが現実的に可能な状況になっています。 ここまではいいのですが、2にすべきか、4にすべきか微妙な状況の組織が多くあります。4に振り切ってしまおうとして色々と困るケースも考えられますし、2で構成したときの無駄やオーバーヘッドも無視できません。 折衷案的なAzure Active Directory Domain Servicesはかなり良い解決策に思えますが、Azureまでのセットワーク接続を安定的に確保するコストが組織に見合うかどうか…。 と、なかなか難しい話題です。 決定にはよくその組織を理解して今後の方向性も含めての決定が必要だよなと思います。曖昧な回答でごめんなさい。 なお、自分に全部決定権があるならもちろん4を選びます。迷わないです。

皆さんこんにちは胡田です。今日は雨が降っていてちょっと残念な土曜日の午前です。30分ほど時間が空いたので少しブログエントリを更新します。 このサイトではフォーラムも設置していますが、投稿はほぼ皆無です。一方、1対1のチャットを設置してみたところ多数質問を頂いています。やはり皆さんプライベートなもののほうが質問しやすい、ということなのでしょうかね。 頂いた質問のうち複数人から質問されていて他の人にも有用そうなものをいくつかピックアップして、解説記事としても公開しておこうと思います。質問者が特定されないようにそのあたりはちょっと気を使って書いています。 ドメイン参加すると何が嬉しいのか？ こちらの質問は姉妹サイトの「ドメイン参加 | Windowsインフラ管理者への道」エントリからの質問として多くいただきました。 ドメイン参加をすると何が嬉しいのかという事に関してはまた別エントリにして、ここでは、ドメイン参加時の設定の意味や良くあるトラブル等に関しての話をします。 と、書いておきながら10年近く記事を書いておらず申し訳ありません…。 ドメイン参加して何が嬉しいのか、ユーザーの立場と管理者の立場で簡単に解説したいと思います。これはActive Directoryのドメインに参加したときの話ですね。 ユーザーの立場からは - どのPCも同じIDとパスワードで利用できる という点が一番便利な点だと個人的に思います。例えばPCが複数台席に設置されていて、好きなところに座って使うような計算機室のような環境ですと、新しいPCを使うときには都度新しいアカウントをそのPCで作ってもらわないと使えない…というのは不便ですよね。このようなときにはPCをドメインに参加させてActive Directory上のユーザーアカウントを共通で利用できるようにしておくと大変便利です。 この時ファイルはどうするの？別のPCに入った時に前回の作業の続きをしたいときには？という疑問が出てくるかと思いますが、そのあたりも処理するために「移動プロファイル」というものもあります。個人の設定、個人のファイル(デスクトップ上のファイルやMyDocumentのファイル)もどのPCであっても使えるようにする仕組みがあります。 便利ですね。 実はこのあたりはもっと深い話が多数ありますが…今回はこの程度にとどめておきましょう。 一方管理者の立場からは - ドメイン参加したPCを一括で管理できる という嬉しい点があります。ユーザーアカウントのお話はすでに述べましたが、ユーザーを作成して、グループを作成して、グループのメンバシップを管理して…ということを個別のPCで1台づつ行うなんて悪夢ですよね。Active Directoryを使えばそれは一箇所で行えばドメイン参加した全てのPCで利用可能になります。 他にも、PCにたいして共通のセキュリティポリシーを一括で設定したいような時には「グループポリシー」という仕組みが使えます。 IDを一元管理できる。PCを一元管理できる。それがドメインに参加させることの大きなメリットです。 が、これって実はWindows NTドメイン～Active Directoryのお話です。今でももちろん現役であり多くの組織がここで書いた管理手法をとっているのですが、Microsoft 365時代にはこの常識は変化します。 Active Directoryを使わずに、Azure ADにWindows10を参加させ、Intuneでデバイスを管理し、Azure AD上のユーザーとグループを使わせながらIDもデバイスも守っていくことができます。クラウドネイティブなしくみでの管理ですね。クラウド時代にはこちらが主流になります。 これから勉強するならActive Directoryへのドメイン参加の概念は理解しつつも、是非クラウドサービスを使った管理手法を学んでいただくことを強くおすすめします。

今回はクラウド時代に「買って済ますべきもの」と「自分たちですべきもの」の話を書きたいと思います。 まず断っておくとこの話は私が全部自分で考えたものではありません。私が敬愛するMicrosoftのJeffrey Snover(@jsnover)さんの受け売りです。ですが、話を聞いたのは今から2年以上前であり、それから色々な人と色々な話をする中でいつもこの話が思い出されます。私のなかでかなり咀嚼したのでオリジナルのメッセージとはずいぶん異なっている気もしますが、私が考えていることを一度文章にしておきたいと思います。 買って済ましているもの、自分でしているもの 世の中には色々となすべきことがあります。原始時代には全てのことを全部自分やごく近くの人で全て行う必要があったのだろうと想像します。衣食住に至るまで全て。 でも、今では社会も複雑になり、様々なものを「買って済ます」ことができるようになりました。というか殆どの物は「買って済ます」の範疇に入ります。着るものはお店で買いますし、食べるものは朝晩は妻に作ってもらっていますが、材料はごく一部を除いて食材は購入しています。昼食に関しては全て買って済ませています。家も自分では建築せずに作ってあったものを買いました。 自分では何をしているのかというと…、例えば子供たちと触れ合うことは自分でやっています。誰かにお金を払って父親の役割を代わりにやってもらうことは私にとっては考えられません。例えば、このブログは自分で書いています。誰かにお金を払って書いてもらうことも可能ですが、私はそれはしません。 父親であることも、自分でブログの文章を書くことも私にとってはそれが「大事」なことであり「自分の時間を投資すべきこと」だという方針と成長戦略のもとで直接自分で取り組んでいます。 買って済ますもの、自分ですること、人によってそのリストは異なるでしょうし、何かが正解だったり不正解だったりするわけではありません。それがその人の人生ですから、個々人の価値基準に基づいて自分の人生の責任をもって決定されるべきことです。 企業において買って済ますべきこと、自分たちですべきこと 企業について考えます。企業の目的…という話になってしまうと、社会貢献であるとか、利益であるとか、いくつか見解の相違も出てきてしまうと思いますが、「差別化要因でないことは買って済ますべき」という点に関してはおおよその方が合意するのではと思います。(個人の生活の話よりは合意しやすいと思います。) 企業としてユニークな存在になるために「買って済ませられない」ことを自分たちで行い、「買って済ますことができる」ことは買って済ませる。 異論反論は細かくはあるとは思いますが、一度この前提を受け入れて、ITの領域に目を移してみたいと思います。 ITは「買って済ますべきこと」か、「自分たちですべきこと」か ITは買って済ますべきことでしょうか？自分たちでなすべきでしょうか？あるいは何が買って済ますべきことであり、何が自分たちでなすべきことでしょうか？ 明らかに買って済ますべきこともあります。PCやサーバーは(特別なものを除き)自分たちで部品を選択してくみたてるのではなく、やはり出来合いのものを購入すべきでしょう。 あるいは、インターネット上でサービスを展開しているケースを考えましょう。やはりこの場合自社の独自サービスは自分たちで企画すべきでしょうし、スピードや継続性を考えれば自分たちで作るべきでしょう。これは例えばMicrosoftがOffice 365やAzureのサービス自体をMicrosoftが企画、設計、構築するのが当たり前であるということです。そこを他社にお願いしていては企業の競争力の根幹が揺らいでしまいます。 一般の企業にとってどこが境界線か？ では、一般の企業にとってはどこまでが買って済ますべきことでしょうか？ 私は個人的に、本当にほとんどのところは買って済ますべきだと考えています。本当に企業としての差異を出す所以外は全部買って済ませていいのではないかと考えていまます。社内に基盤を構築する所は企業の差異を出せるところではありません。だからパブリッククラウドを積極的に利用すべきだと思いますし、IaaSを使って自分たちで仮想マシンの管理をするのではなく、極力PaaSを使ってプラットフォームの面倒は見なくてよいようにすべきですし、可能であれば極力SaaSを使うべきだと考えます。 この考え方は特に「インフラエンジニア」の方には受け入れがたい考え方だと思います。まさに自分が今している仕事の大部分が「なくなったほうがいい」という話だからです。 それでも私は自分がインフラ構築の仕事を長い間続けてきて色々な苦労をして、たくさんの勉強をして、それでももう自分では仮想基盤を構築したくないですし、仮想マシンの管理をしたいとは思いません。コミュニケーション基盤はOffice 365で良いと思いますし、ID管理はAzure ADで良いと思いますし、デバイス管理はIntuneで良いと思いますし、なにかロジックを組みたくてもまずはサーバーレスで考えますし、極力PaaSを使います。オンプレミスに環境が必要ならAzure Stackを選択します。はやくAutoPilotが広く普及して管理者の手を煩わせずにPC展開できるようになってほしいと思います。 買って済ますべきところを極力買って済ませたしてもやはり残るところは残りますし、他者との差別化の部分にこそ開発リソースを使うべきだと思います。 日本においてまだこの考え方になっている組織にはほぼ出会っていないのですが、Igniteで海外の管理者に話を聞くと「これからはServerlessだ！」と多くの人が言ってました。このような考え方が日本でも広まってくれると良いなと思っています。

マイクロソフトのクラウドサービスを利用しようとしたり、クラウドプラットフォーム上で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を利用して全てのものを利用可能とするのが最も便利でセキュアで運用コストが低いから」です。この点はもっと説明が必要ですのでまた今後のブログエントリで解説していきたいと思います。

このサイトはWordpressで構築されています。Azure上のサービスであるWeb App for ContainersにDocker Hub上の「wordpress」コンテナイメージを元にカスタマイズしたコンテナイメージを展開して動作させています。 Web App for Containersは本記事執筆時点の2018年３月現在では相対的に新しいサービスであり、これを使ったWordpressサイトの構築手法に関してはまだあまり情報がなかったため、備忘録も兼ねて構造を書き残しておきます。 全体像 下図がシステムの全体像です。 実行環境は全てAzure上にあり、１つのリソースグループに格納されています。 App Service on Linuxにより環境が定義され、その上でWeb App for Containerが可動しています。 Wordpressはコンテナ上で実行されています。 データベースとしてはAzure Database for MySQLを利用しています。 App Serviceドメインにて独自のドメイン(ebisuda.net)を取得、割当しており、DNSもAzure DNSを利用しています。 Web App for Containersに展開するコンテナイメージはDocker Hub上のカスタムイメージとして公開されています。 https://hub.docker.com/r/ebibibi/appservice-wordpress/ Web App for Containerにてこのコンテナイメージを利用するように設定を行っています。 Docker Hub上のこのコンテナイメージは、Git Hub上のレポジトリがソースに指定されています。 具体的には下記のレポジトリがソースです。 https://github.com/ebibibi/appservice-wordpress このレポジトリ内にDockerfileが記載されており、このDockerfileの記載内容に従ってコンテナイメージがビルドされます。 このGitHub上のレポジトリを手元のPCにクローンしVSCodeにて編集している状況です。 コンテナイメージ更新の流れ なにか設定を変更したい場合には手元のVSCodeにてDockerfileを編集することであとは全自動でWeb App for Containerまで展開されるようにしています。流れは以下となります。 - VSCodeにてDockerfile編集 - VSCodeからGitHubレポジトリへgit push - GitHubレポジトリとDocker Hubの連携機能によりpushが検知される - Docker Hub上でコンテナイメージの自動ビルド - Docker Hub上でのビルド完了時にWeb App for ContainerのWeb Hook URLに対してPostが実行される - Web App for ContainerがDocker Hubからビルド完了済みの最新イメージを取得 - 更新された最新イメージが実行される 体験としては、手元のVSCodeで必要な編集を行い、コミット、プッシュするのみであとは全自動のため非常に快適です。 ...