Exchangeのメールボックスは昔は「一番最初にアクセスしたクライアントやプログラム等の言語」によって言語が決定される…という動きだったと思うのですが、Exchange Onlineになって、どうやらユーザーの言語設定に応じてメールボックスのフォルダ名の言語が変化する仕様になった模様ですね。 とりあえず全部日本語にしちゃいたければ下記のようにしてしまえば良いです。実行環境はAzure CloudShellで大丈夫です。
シリーズ記事の10個目です。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 今回の記事では、IntuneからWindows 10端末にOffice Pro Plus を配布するように設定してみたいと思います。 Intuneの配信設定 クライアント側挙動 クライアント側で同期しつつ、状況を確認します。 特に何も画面には表示されていませんが、裏でインストールが走っているようです。 ...
皆さんこんにちは。胡田です。もう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のサブスクリプションを指しての言葉なのか等、しっかりとその意図するところを確認する必要があるでしょう。 「テナント」という言葉は注意して使いましょう というわけで、今回はなんだか締まらない内容になってしまいました。それだけ曖昧な言葉であるということです。話し手、書き手の意図をきちんと確認し、思い込みで誤解を生まないようにしていただければと思います。
継続的にチャットにて質問をいただいております。結構会話が弾むこともありなかなか楽しいです。 私には会話相手が誰だかわからない状態から会話が始まり、継続的にフォローを希望する方はメールアドレスを登録してもらう事で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を選びます。迷わないです。
オンプレミスの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を利用して全てのものを利用可能とするのが最も便利でセキュアで運用コストが低いから」です。この点はもっと説明が必要ですのでまた今後のブログエントリで解説していきたいと思います。