果たしてOutlookだけで100時間の時短を達成できるのか?

それを確認するには、自分がOutlookを使っている時間数を調べる必要がある。上記の本によれば一般的なホワイトカラーのOutlook利用時間は500時間/年であり、この場合に100時間/年の時短が出来る、とある。

関連エントリ:「年間100時間の時短を実現した32のテクニック アウトルック最速仕事術」を読み込んで改善点を考える

Outlookを起動している時間を調べる

RescureTimeというソフトをインストールする事で、PCで使用しているソフトの利用時間を計ることができる。以下、2019年3月の私のデータ。

Outlookの使用時間は16時間12分。年間使用時間にすると194時間24分。これを100時間にするのは難しそうだが、50時間減くらいなら期待できそう。

ちなみにOutlookより上位のソフトウェアは

  • Microsoft Teams:25時間45分(年換算:309時間)
  • Excel:25時間1分(年換算:300時間12分)
  • PowerPoint:24時間58分(年換算:296時間24分)

なので、Outlookよりも上記ソフトの時短の方が効果があるのだが、以下の理由で時短が難しそう。

  • PowerPoint
    • 手を動かすというより、資料を見たりアイディアを練ったりする時間が大半なので時短効果はなさそう、
  • Excel
    • 既にいろいろExcel本を読み漁ってこの時間なので、単純に触れてる時間が長いだけ、
  • Microsoft Teams
    • アプリ自体がもっさりしており、満足なショートカットキーも用意されておらず時短しようがないので諦めます。マイクロソフト様、時短ハックできるTeamsクライアントをお待ちしています。

それにしても、Teamsがない時代はほぼすべてのコミュニケーションをOutlookでやっていたので、Outlook利用時間(194時間24分) + Microsoft Teams利用時間(309時間) = 年間約500時間もOutlookを利用していたことになる。これならマジで100時間くらいは時短できるかも。

メールの利用時間を調べる

Office 365 を利用しているなら、MyAnalyticsという機能で自分が読んだメールの数・送信したメールの数をカウントする事が出来る。以下は3月第1週目の私のデータ。

2019年3月第1週~第4週の集計は

  • 送信メール:129通
  • 既読メール:1299通
  • メール利用時間:21.4時間

であった。なお時間は単純計算で、送信メールは1通につき5分、既読メールは1通につき2.5分、ただし、連続して既読操作、例えば10通一気に既読にしても2.5分加算となる。詳しい計算方法は以下参照。

MyAnalytics ダッシュボード – Workplace Analytics Office 365 | Microsoft Docs

RescureTimeの16時間42分に比べると少し多いが、メール1通を2.5分かけて読むことはないので、少しMyAnayticsの計算が過剰なように思える。

まとめ

次エントリ年間100時間の時短を実現した32のテクニック アウトルック最速仕事術の紹介をするが、そもそも自分がOutlookを利用していないと意味がないので、事前に調査しておくのが良い。僕に本当に必要なのはMicrosoft Teams時短ハックです。

余談:RescureTimeについて

上でも書いた通り、起動しているソフトウェア毎に起動時間を取得し、レポートしてくれるソフトウェアである。ブラウザでのアクセスの場合、アクセス先のサイト情報も取得してくれる。

元々、ダラダラとyoutubeを見てしまう自分を戒めようと思い導入したのだが、生産的なソフトウェア(Outlook・Excel)、非生産的なソフトウェア(Chromeでyoutubeを見る、LINE)を分けて集計してグラフィカルに表示してくれるので便利。月毎の比較もでき「前月に比べてX時間生産的な時間が増えた」というレポートも出してくれる。PCのフロントウィンドウになっているソフトウェアの情報を取得しているだけなので、Excelを起動したまま離籍したり、youtubeを流したまま寝落ちするとその時間も加算されるのだが、絶対時間ではなく週毎、月毎のデータで比較する事で肌間隔的に分かる(今週は先週に比べて頑張ったな)ので、ひとまずいいかな、と。

今後、ここで取得したデータを元に自分の行動を変えていけたら、と思っている。

「年間100時間の時短を実現した32のテクニック アウトルック最速仕事術」を読み込んだ

はじめに

年間100時間の時短を実現した32のテクニック アウトルック最速仕事術は時短ハックの対象としてOutlookにフォーカスした本であり、その着眼点と内容もすばらしく、年間のOutlook利用時間が多いが特に使い方を工夫していないユーザー、また工夫しているがより良い使い方があるかを確認したいユーザーは購入必須である。

私としては、自分なりにOutlookを工夫して使っており、Outlookを人に教える事もある立場であるため、あえて批判的な視点で本書のテクニックを確認していくが、本書の基本的なコンセプト「普段意識しないOutlookの使い方を見直し、時短につなげる」は大賛成であることは記載しておく。

これを機にOutlook時短ハックブームが起こり、みんながOutlookの効率的な考え方についてあーでもないこーでもないと議論できる世の中になれば私も本望である(それはなさそう)

本書のテクニック一覧と、私の評価

2章:画面の使い方編

Case1:予定表を固定する

著者の意見

メール一覧画面の右ペインに予定表を固定し、いちいち予定を確認するために予定表ビューに移動しなくてよいようにすべし

私の意見

ディスプレイが広い場合は賛成だが、狭い場合はメール一覧画面が小さくなって、「メッセージのプレビュー」機能による本文表示(≠閲覧ウィンドウ)領域が小さくなり、かえって情報量が少なくなる。タスクバーを立て置きにしている場合はなおさら。自分の予定の量の多さと相談して、何をランディングページ = メールの一覧画面に表示するかを検討すべし。

下に比較画像を配置した。

・メール一覧画面だけ
右側の領域に情報量が少なく非効率な気がする

・メール一覧画面 + 予定表ビュー
ちょうどいい情報量

・メール一覧画面 + 予定表ビュー + タスクバー
メール一覧画面の情報量が少ない気がする。

Case2:添付ファイルは最初につける

著者の意見

クリップボードにファイルを選択した状態でメールに張り付けると、ファイルが添付された状態の返信メールが立ち上がるので有効活用すべし

私の意見

私の添付ファイル付きメールの送信数を調べたら月に20通くらいだったので、仮にこのテクを利用してもあまり時短は望めないように思えた。また、メール処理のプロセスが

  1. 受信トレイのメールを見る
  2. 対応必要そうなものは返信メール画面を起動
  3. 本文を書いて添付ファイルをつける

なので、2の時点でこのテクニックは使えない。このテクニックを使うには、自分のメール処理のプロセスを変える必要がある。

Case3:予定表から新しいタスクを起動しない

著者の意見

クリップボードにテキストをクリップして予定表ビューの時間帯を選んでペーストすると、予定が作成される機能を使うべき

私の意見

反映されるのはクリップボードのテキストだけであり、添付ファイルはペースト出来ないのが欠点。本書では「イベントへの招待のメールを予定表に張り付ける場合」に便利とあるが、それに添付ファイルがあった場合、結局.msgファイル自体を予定表に張り付ける必要があるので、

  1. 受信トレイの招待メールをクリップボードにコピー(この時点で、.msgファイルとしてクリップ)
  2. Ctrl + Shift + Qで空の予定表アイテムを起動
  3. ペースト(.msgファイルがペーストされる)

が最速の手段となる。.msgファイルを新規アイテムに張り付ける”入れ子のメッセージ機能”はメッセージそのものを完全に保管できるので結構優秀。余談だが、Office 365 の場合、30入れ子までの動作をサポートしている。

Case4:メールの閲覧ウィンドウは使わない

著者の意見

メールの閲覧ウィンドウは画面占有率の割に情報量が少ないので閉じるべし

私の意見

賛成。余白が多く、無駄である。私は「メッセージのプレビュー」機能を利用し、2行ほど本文を表示しサマリが分かるようにしている。全文を読みたい場合は、著者の意見通り、別ウィンドウで開いている。

Case5:リボンは閉じる

著者の意見

ショートカットキーを使いこなせばリボンは不要だから閉じるべし

私の意見

メールの読み書きなら不要だが、予定表を利用するときはショートカットキーだけでは操作できない事が多いので閉じない方がよい。例えば予定を「非公開」にしたり、公開方法を「空き時間」にするのはショートカットキーが用意されておらず出来ない。

私からはリボンの代わりによく使うボタンをクイックアクセスツールバーに集約する事を提案したい。PC毎に設定が必要という欠点はあるが、これでリボンを表示させなくても済む。

例えばTeams会議開催ボタンをツールバーに追加したり。

3章:ショートカット(基本編)

この章のショートカットは知っていて当然レベルでマスターしたい。以下を本書への補足。

  • 返信(Ctrl + R)で紹介されている全員返信(Ctrl + Shift + R)はCtrl + Lでも可能。→Alt + Lでした。
    • ビジネスでは全員返信でメールを作成する事が多いので、返信 = Ctrl + L→Alt + Lで覚えた方がよい。
    • (2019年5月2日追記)著者から指摘あり、全て左手で操作できる統一感と、なるべくCtrl系でショートカットは統一したかったのでAlt + LよりもCtrl + Shift + Rにしたとの事です。
  • 閲覧ウィンドウを閉じる(Esc)はAlt + F4でも代用可能。
    • Alt + F4はWindows全般で有効なので、これで閉じてしまってもよい。
  • 次 or 前のメールへ移動(Ctrl + < or >)は、Ctrl + 4 or 5でもOK。
    • これはショートカットバーに前後のメールに移動するボタンが標準で表示されているから使える。
    • <と>はPCによっては位置が探し辛いので、4と5で覚えるのがよい。

4章:メール整理

著者の意見

仕訳ルールは使わず、アーカイブフォルダを上手に使え。仕訳したくなったら検索フォルダを使え。

私の意見

仕訳ルールを作ってフォルダ分類派 VS メール処理状態で整理派の仁義なき戦いである。まず大事なのは、どちらも試して、自分に合った方法でやってみる事である。また、環境が変わった場合、やり方を見直すのも重要である。

なお私はどちらも試して仕訳ルールを作ってフォルダ分類するやり方に落ち着いたが、この本を読んで数年ぶりに仕訳ルールを全削除し、メール処状態でフォルダ整理運用にした。なぜなら、数年前に試した時はビジネスチャットツールであるMicrosoft Teamsがなく、全てのコミュニケーションをメールでやり取りしていたが、今は大半がTeamsに移行し、メールの総数が減ったからである。新規OAツールが導入されたり転職したりして環境が変わった場合、今までのやり方が最適ではなくなる可能性があるため、環境が変わる前に自分のやり方を見直すことが重要である。

なお著者が推薦している検索フォルダはOWAやOutlook for iOSでは利用できないため、ブラウザやモバイルデバイスからメールを利用することが多い場合、検索フォルダに頼ることは出来ない。本書は全般的にデスクトップ版Outlookでメールの処理をする事に主眼が置かれているため、自分の使い方がどの程度合致しているかを見極めて読む必要がある。

5章:もっと時短したい人のためのスーパーテクニック

クイック操作 / クイックパーツ

著者の意見

自分好みにクイック操作やクイックパーツを利用すればもっと時短できる。

私の意見

この2つの機能は自分のOutlookの利用方法を分析して、使い方を検討する必要がある。例えば「クイックパーツで定型文を登録すれば時短になる」と著者は主張するが、私の場合、月のメール送信数は129通(前エントリ:果たしてOutlookだけで100時間の時短を達成できるのか?の調査結果参照)。この129通のうち、定型的な内容で返信しているメールが何通あり、クイックパーツによってメールを作成する事で短縮できる時間は何分か?

日本人の平均タイピング速度は100文字(ひらがな)/分らしいので、クイックパーツが100文字程度であれば、1通につき1分ほどの時短。クイックパーツで作成できるメールが10通あれば10分の時短、年間では120分の時短となる。しかしながら、そのためにテンプレートを作成し、クイックパーツを設定し、送信するタイミングでクイックパーツを思い出すコストはどうか?ついつい手打ちしてしまうこともありそう。

なお私の場合、129通のメールで定型的な内容で返信しているメールは2通だけだったので、絶対に普通に返信した方が早いです。自身の毎月のメール送信数を調査し、効果を算出してから、取り組むのがよい。

Oftファイルでのスケジュール確認機能

著者の意見

Oftファイルの宛先に同僚のメールアドレスを登録することで、スケジュールアシスタントから簡単に予定を確認できる

私の意見

予定表グループでも同じような事ができるのに、なぜOftファイルでスケジュール確認をするのかよくわからなかった。
もし、(予定表グループの)予定表ビューを使った予定表閲覧は時間がかかるから、あえてスケジュールアシスタントから確認したい、というのなら、同僚のメールアドレスを連絡先や連絡先グループに登録して、会議出席依頼から確認すればよいと思った。

なおOftファイル自体は有用な機能であり、例えばヘルプデスクで定型文をグループで共有する場合、グループでアクセス可能なディレクトリに返信テンプレートを配置し、それを元に返信する、という事が出来る。

(2019年5月2日追記)著者から指摘あり、Oftファイルは、部内のファイルサーバーなどで共有して利用する想定、とのことでした。確かにこの使い方なら、自分の予定表グループをメンテするより、グループ全体で利用できるからいいかも。一番いいのは、システム管理者が組織構造に合わせたグループを作成し、グローバルアドレス帳に公開することだと思うが。

メールの1分遅延ルール

著者の意見

クライアントルールで1分遅延ルールを設定すると無料で誤送信防止ができる

私の意見

これはマジお勧めで、著者の提案する例外ルールを設定するのも併せてお勧め。注意点としてOutlookで送受信タスクが走るタイミングで、送信トレイに1分以上保管されたメールが送信されるので、最速で1分、最遅で2分くらい、送信にかかること。あと、Outlookのクライアントルールになるので、OWAやOutlook for iOSの時には適用されないので注意。

6章:もっと時短したい人のためのショートカット

気になったところだけ。

Ctrl + Space = 標準書式に変換

これは知らなかったので活用している。Outlook以外から文章をコピーした場合にMeiryoで統一されたフォントにMS ゴシックがまざってイラっとしてしまう所がこれで直せるのは便利。

Ctrl + Shift + I で受信トレイに移動

これは知らなくて便利だと思いました。が、送信済みトレイに移動するショートカットもほしかった。

署名のショートカット

クイックアクセスツールバーに登録する事で、Alt + 1で署名のショートカットを呼び出せる、というテクニック。だが私はOutlook標準のショートカットである、Alt -> N -> AS で署名を呼び出してます。慣れれば1秒かからない。

仕事柄、複数のPCでOutlookを使うことがあるので、ソフトウェア固有の設定をいじるのが煩雑で管理しづらく、出来るだけ標準ショートカットで済ますようにしています。

Shift + 右クリック = パスをコピー

これは自社の共有ストレージが

  1. 全員が同じUNCパスでアクセスできるファイルサーバーか
  2. https://~でアクセスする、オンラインストレージか

で有用性が変わってくる。うちの会社はほぼファイルサーバーが廃止されSharePointが主要ストレージ。SharePointのファイルにアクセスするには

  1. ブラウザからファイルを選択する
  2. OneDriveで同期して、ローカルファイルとして開く

の2通りがあるのだが、2で同期したファイルのパスは自分のPC固有のパスとなり人に送っても開けない。

よって、https://で始まるパスを人に伝えなければならないが、この時に便利なのが「ドキュメントの場所」というクイックアクセスツールバー。

Alt + 数字で、ドキュメントを開いたままパスをクリップボードにコピーできる。

編集し終わったファイルのパスを誰かに伝える、という利用シーンを考えても、わざわざエクスプローラーに戻ってパスをコピーするよりも有能。「ソフトウェア固有の設定をいじるのは嫌」といいつつ、これだけは代替のショートカットがないので、設定している。

また余談だが、book1.xlsxのような一時的なドキュメントを他人にシェアしたい時、一度PCに保存してからメール添付ではなく、ワンボタンでメール添付できるような機能も設定している。

まとめ

本書の基本的なテクニックは抑えるとして、応用編は自分のOutlookの利用分析を行った上で適切なテクニックを覚るのがよいと思う。特にクイック操作、クイックパーツ、クイックアクセスツールバーは使う人と設定内容によっては福音になる(SIerとしても一度これを使った業務改善を提案した = カネが取れる)ので、Outlook利用頻度が多い人は研究してほしい。

一方、予定表の活用テクニックがあまり記載されていなかったのが弱点かと思われるが、Outlookでメールは使っているが予定表は使っていない会社は意外と多い事、メール利用に比べて予定表利用の方が個別最適化されて汎用化しづらい事から、書籍として出すのは難しかったのかな、と思う。

全てのテクニックが有用だとは思えないが、冒頭にも書いたが、みんながなんとなく使っていたOutlookに光を当てたという点で、本書は素晴らしいです。著者は「Excelのスキル本はあったがOutlookはなかったので書いた」と言っているが、ExcelはVLOOKUPを使わなければ出来ないことはあるが、本書のOutlookテクを使わないと出来ないことは、正直言ってない。しかしながら、Outlookは万人が使用し、VLOOKUPと違って全員に効果があるテクニックが本書には書かれてますので、Outlook主体の業務の人は是非チェックしてみてください。

なお私はMicrosoft Teamsの使い勝手が良くなることを心より期待しています。

onmicrosoft.comがバレると何が困る?

前回のエントリの続きです。

onmicrosoft.comをどうしても隠蔽したい – ぷりどうぐ

前回のエントリの結論:xxx.onmicrosoft.comを隠し通すのは難しい

onmicrosoft.comがバレると何が困る?

困る事もありますが、別にそうじゃなくても既にバレてるので困らないこともあります。

Office 365 を利用している事がバレる

xxx.onmicrosoft.comがバレる = Office 365を使っている事がバレるので、フィッシングメール送って偽のログイン画面に誘導できたりする。ただOffice 365利用しているかどうかは会社のメールアドレスを知っていればnslookupで一発で調べられるので、xxx.onmicrosoft.comを隠しててもバレます。

結論:どっちにしてもバレてるので無影響

AADログインIDのonmicrosoft.comドメイン部分がバレる

会社のログイン用ドメインはメールアドレスと同じ場合が多いので当然外部にバレてるとして(※)、新たにxxx.onmicrosoft.comのドメインがバレると、xxx.onmicrosoft.com を利用したユーザーIDを探してログイン施行することが出来ます。企業のもつアカウントの99%くらいは会社ドメインのログインIDなので問題なさそうなのですが、xxx.onmicrosoft.comを持つIDはシステム導入時やテスト時に作ったまま放置しているアカウントだったりして無防備なことが多いので、事実上、問題になる事があります。

※ まれに「悪意のある外部ユーザーからログイン施行されないため、ログインする会社ドメインをメールアドレスと別のものにしたい」という要望を受けますが、ゼロトラスト理論を考えるとそれこそ隠し通すことが難しく、ユーザー利便性だけが低下するのでやめた方がいいと思われます。

結論:アカウントが存在する場合は問題あり

onmicrosoft.comのセカンダリメールアドレスがバレる

Office 365 の仕様上、各ユーザーのセカンダリメールアドレスに[ユーザーID]@xxx.onmicrosoft.comというメールアドレスが付与されるので、スパムメールを送りやすくなります。とはいえ、セカンダリメールアドレスを指定しなくても普通に会社ドメインのメールアドレス[ユーザーID]@xxx.co.jpにメールを送り付ければいいので、onmicrosoft.comがバレたことによって新しく困る事ではありません。

結論:どちらにしろメールは受信できてしまうので、無影響

SharePointサイトのURLがバレる

会社のイントラのURLがバレるので気持ち悪い、という意見。とはいえ、SharePoint外部共有やTeams外部招待、OneDriveファイル共有を許可している会社なら、自サイトへのユーザーアクセスを許可しているわけで、今更会社のイントラURLバレを気にするのもナンセンスかと思います。

SharePoint外部共有とかしてないから、イントラのURLがバレるのが気持ち悪い!というのは感覚としては分かりますが、メールと違って権限管理をすれば外部から見れないので全く実害はないです。

※ むしろメアドさえ知ってれば誰でもメールを送れてしまうメールの仕組みがすごい

結論:デフォルトで外部の人は見れないから、バレたところで無影響

結論まとめ

AADログインIDのonmicrosoft.comドメイン部分がバレるのが、onmicrosoft.comがバレることによる新たなデメリットと考えます。

ログインIDがonmicrosoft.comのアカウントってどんなの?

xxx.onmicrosoft.comを利用したユーザーIDを抹殺すればよいですが、そんなことはできるのでしょうか?どのようなアカウントがonmicrosoft.comを使うのでしょうか?

認証回避

結論から言うと、一般ユーザーアカウントに対して多要素認証などを仕掛けている場合に、多要素認証トラブル時のシステム復旧用に、多要素認証を回避するためのアカウントを用意するパターンでonmicrosoft.comドメインを使う場合があります。

フェデレーション認証環境の場合

O365の世界でフェデレーション認証は認証ドメイン単位で設定するので、例えば会社ドメインはフェデレーション認証、としてしまうと、緊急回避用アカウントは会社ドメイン以外で作成する必要があります(※) ここで、既定で用意されているxxx.onmicrosoft.comを認証用ドメインとすることがあります。

以下の記事でもそれが推奨されています。

緊急アクセス用管理者アカウントの管理 – Azure Active Directory | Microsoft Docs

※ 緊急回避用アカウントを会社ドメインで作成しつつ、フェデレーション先のIdPで多要素認証をかけないこともできるが、どちらにせよIdP自体が死んだときは影響あり

AzureAD認証環境の場合

AzureAD認証環境の場合、認証制御はEM+Sの機能で行います。EM+Sの制御単位はユーザー個別orセキュリティグループであり、認証ドメインがなんであるかは関係ありません。よって、緊急回避用アカウントを会社ドメインで作成しても問題ありません。

結論

  • フェデレーション認証環境の場合は、会社ドメイン以外のドメインで、緊急回避用アカウントを作成する必要がある
  • AzureAD認証環境の場合、会社ドメインで緊急回避用アカウントを作成すればよいので、onmicrosoft.comでログイン可能なアカウントを抹殺できる

一歩進んで考察

さて、フェデレーション認証環境ではonmicrosoft.comのアカウントが必ず必要なのでしょうか?会社ドメイン以外のドメインで、緊急回避用アカウントを作成する必要があるという条件を満たせばいいので、例えば @hogehogetest36512345678.com というドメインを取得し、Office 365 に紐づけ、emergencyadmin@hogehogetest36512345678.com みたいなアカウントを作成し、、この条件を満たせますよね。

よって、ADFS環境でonmicrosoft.comの緊急回避用アカウントを作成する必要はなく、会社ドメインとは別の、AzureAD認証を利用するドメインを用意すれば、ADFS環境でもonmicrosoft.comも抹殺できます。

しかし果たしてこれに本質的な意味はあるのでしょうか?

emergencyadmin@hogehogetest36512345678.comと、
emergencyadmin-hogehogetest36512345678@xxx.onmicrosoft.comは「複雑で推測されにくい」という点で、何が違うのでしょうか?

上司に「なんでhogehogetest36512345678.comってドメイン取るの?」って聞かれて、ロジカルに答えられるでしょうか?
hogehogetest36512345678.comのドメインを維持する労力や、ドメイン失効リスクの方が、onmicrosoft.comを利用されるリスクよりも高いんじゃないでしょうか?

相次ぐドメイン事件、目的のWebサイトが表示されない原因 | 日経 xTECH(クロステック)

と考えると、素直にxxx.onmicrosoft.comのドメインを利用し、緊急回避用アカウントのIDを複雑にすることで(もちろんパスワードも)十分に要件を満たせるのではないでしょうか?

AzureADの素のセキュリティ

EM+S使わないと脆弱だ!みたいな説もありますが、AAD素の機能でそれなりのセキュリティレベルは担保しています。例えばID/Passwordを複雑にする、という対策は、IdPが総当たり攻撃を許してしまえば全くの無力ですが、当然その対策はされています。

詳しくは以下エントリを読んでもらいたいし、私も昔に説明エントリ書いてました。

Azure AD と AD FS のベスト プラクティス: パスワード スプレー攻撃の防御 – Japan Azure Identity Support Blog
Azure AD スマートロックアウトのカスタマイズ機能について-ぷりどうぐ

よって、IDもパスワードも複雑にしておけばまず大丈夫、と言えるでしょう。

結論

  • ADFS環境でもonmicrosoft.comのログインIDは抹殺できるが、ナンセンスで無意味なので、onmicrosoft.comのIDを抹殺する意味はない。
  • AzureADのセキュリティ機能を信用し、辞書攻撃にヒットしないようなID/Passwordを作れば、AzureADが総当たり攻撃には対応してくれる。

onmicrosoft.comをどうしても隠蔽したい

お客様より「xxx.onmicrosoft.comは外部にバレたくないしユーザーにも見せたくない」という要望を受けますが、実現可能なのでしょうか?

xxx.onmicrosoft.com とは?

Office 365(Microsoft 365)の契約毎に割り当てられる一意のドメインであり、契約後は変更不可。独自ドメインを持っていないユーザーや、検証環境で気軽に使えるようにと用意されたものだが、本番環境では会社のドメイン(xxx.co.jp)を使うのが普通であり、xxx.onmicrosoft.comは不要となる。

※ 私のテナント。myalmea.onmicrosoft.com が xxx.onmicrosoft.com であり、Office 365 契約時に割り振られるもの(名前は自分で選べる)。almea.jpが自分所有のドメイン。

以下、本番環境であることを前提に話す。

なぜ隠蔽したいのか?

よくある2大理由。

1. ユーザーに見せたくない

会社ドメイン xxx.co.jp しか利用していないユーザーが突如 xxx.onmicrosoft.com を見てしまったら「xxx.onmicrosoft.comって何ですか?スパムですか?」とユーザーの混乱を招き、不要な問い合わせが発生する可能性がある。

2. セキュリティ的によろしくない

理由はいろいろありますが、onmicrosoft.comを利用してクラッカーに狙われる恐れがある。詳しくは別エントリ。

onmicrosoft.comが表示されちゃう場所

SPO、Skype、ExOL、Teamsの四天王を論じる。Swayとかは知らん(私がナレッジなし)

SPO(OneDrive)

SPOサイト自体にxxx.sharepoint.comという名前付けがされるので、内部ユーザーには見えてしまう。例えば、自分のOneDriveを利用するときに見える。SPOやOneDriveで外部共有をする場合、xxx.sharepoint.comが含まれる形で共有するため、外部ユーザーにバレてしまう。

Skype

Skypeはテナント側でデータベースのようなものは持たず、あくまで個人の連絡先を情報として閲覧できる形となる。連絡先はAzure AD のSIPアドレスが見えるため、こいつが会社のドメインであれば、xxx.onmicrosoft.comは見えなかったはず(最近構築してないから怪しい
まぁほぼTeamsに置き換わってるからいいや…。

ExOL

明示的にメールアドレスを付与しなければ、[ユーザー名]@xxx.onmicrosoft.comというメールアドレスが付与される。明示的に会社メアドを付与した場合でも、セカンダリアドレスにというアドレスが強制的に付与されるので、[ユーザー名]@xxx.onmicrosoft.comでメール受信ができてしまう。

「明示的にメールアドレスを付与しなければ」というのは、Teamsでチームを作成した時にも当てはまるので、ユーザーが自由にTeamsを作れるシナリオだと、作るそばから@xxx.onmicrosoft.comで送信可能なメールボックスが出来上がっている(※)、ということになる。

※ 2019/4/23追記
Teamsからチームを作成した際に出来る共有メールボックスに対しては「メールボックス所有者として送信する」権限が付与されないので、設定変更なしにメールを送ることはできませんでした。すいません。

また、国井さんのブログにもあったが、メアドを隠蔽してもO365の仕様上、テナントからメール送信時にDKIM署名をするので、ヘッダーにxxx.onmicrosoft.comのドメインが記録される

Teams

ユーザーとしても管理者としても利用していますが、onmicrosoft.comが見えてしまう場面はない。ただこれはTeamsのUI上では、という条件付きであり、裏側のSPOやExOLを開いた瞬間にxxx.onmicrosoft.comがバンバン見える。これはSPO,ExOLの項目で説明していく

隠ぺいの検討

SPO

内部アクセスの際にxxx.onmicrosoft.comの代わりにxxx.co.jpを使わせるよう、内部DNSにCNAMEを記載して隠蔽することが出来る。しかしnslookupでCNAMEの変換先を引けばバレてしまうし、ファイル共有を使うと自動的にonmicrosoft.comを含まれるアドレスが発行されるので隠蔽は難しいと思う。

ExOL

メールフロー

トランスポートルールでxxx.onmicrosoft.comが含まれるメールは破棄する設定にしておけば防げる。ただ、マイクロソフト社からの通知メールなどがxxx.onmicrosoft.com宛に送られてきても破棄するので注意する。前に問い合わせた時は、通知メール系はプライマリメールアドレスを見ているとのことなので、管理者IDをxxx.onmicrosoft.comのまま運用する場合は、UPNはそのまま、プライマリメールアドレスをxxx.co.jpにしておく。

セカンダリアドレス

ユーザーオブジェクトにはxxx.onmicrosoft.comが付与されたままなので、Outlookの連絡先カードを使うと一般ユーザーでもxxx.onmicrosoft.comの確認が可能。隠蔽不可。

DKIM署名

DKIM署名にxxx.onmicrosoft.comが記録されちゃう問題は、DKIM署名を無効にすることで回避できる。

DKIMを無効にする賛否はあれど、日本国内では4割程度の実装であるため無効にしても即スパムとは扱われにくい事、3rdパーティーMTAをかませて、そこでDKIM署名を行うことで回避できること、DMARKを使うことが代替策となる(DMARKだけは実装したことないので、実はこいつもonmicrosoftを外に出す可能性はある)

まとめ

内部漏洩

SPOのサイト、OneDriveの自領域、Outlookより自分の連絡先情報を見る、など手段がありすぎて隠蔽は難しい。

外部漏洩

自テナントのSPOサイト(OneDrive含む)にアクセスさせない、メールフローの隠蔽、DKIM署名の削除で対応できる。

よって、バレるのは内部ユーザーだけなので安心!…というわけにはいかず。ゼロトラスト理論だと内部ユーザーを信用しないし、仮に信用してもこんだけ埋め込まれてたらどっかから漏れるでしょということで、バレる前提で考える、隠蔽するのに無駄な工数をかけない方がよいと思いました。

Azure SentinelでOffice 365 のデータを取り込んでみた

※ 本エントリは単純にAzure Sentinelを有効にしただけで、特に深い考察はありません。

唐突に”Azure Sentinel”なるものがリリースされました。

O365やAzureだけではなく、さまざまなログを取り込んでリアルタイムでモニタ出来る、というどこかで聞いたことあるサービスです。現在はプレビューなので無料ですが、「Office 365アクティビティデータの取り込みは、サービスの本格提供開始後も無償」とのことなので、さっそく取り込んでみました。

続きを読む

Exchange Server 2013以降に存在する脆弱性”PrivExchange”の内容と対処法(とその影響)

本記事は英文記事をベースに実機検証なしで書き上げたものであり、内容が誤っている可能性があります。本記事を参考にしたことで問題が発生しても責任は取りませんのでご了承ください。

ドメインユーザーのID/Passwordだけでドメインコントローラーを乗っ取れる、衝撃の脆弱性が発見されました。

脆弱性の内容

今回の”PrivExchange”は、Exchange Serverの複数の脆弱性/設定を組み合わせて動作するものです。

1.EWSの”PushSubscription”を利用して、Exchange Serverに認証行為を開始させる

最初にExchange ServerのEWSを利用します。EWSの”PushSubscription”機能を利用すれば、Exchangeに対して任意のURLに対して認証を行わせることが可能です。この例では、Exchange Serverに命令して、攻撃者のPCに対してExchange Server権限で認証を試行させます。

※ EWSを利用するため、ExchangeユーザーのID/Passwordを利用します。

で、元記事の”Performing the attack without any credentials altogether”にあるのですが、ネットワークパケットをコントロールできる立場なら、ユーザーのID/Passwordを知らなくても、同一セグメントの一般ユーザーの認証パケットをExchange Serverに投げることで同じことが出来ます。

2.NTLM認証にハッシュが付与されていないため、中間者攻撃を行うことが可能である。

これはExchange Serverではなく、昔からWindows Server自体に存在する脆弱性となります。以下、2004年(15年前)の記事。

Windows NTLM認証とマン・イン・ザ・ミドル攻撃

1.でExchangeに対して攻撃者のPCに認証を行わせるように仕向け、その認証をDomain Contorollerに転送することで、中間者攻撃が成立します。これにより、攻撃者のPC = Exchange Serverのコンピューターアカウントに成りすますことができます。

で、ここが記事を読んでもいまいちわからないのですが、おそらくDomain Controllerが受け付けられる認証方式ならなんでもいいようです。具体的には、ExchangeユーザーのID/Passwordを使って認証を成功させるパターンの場合、HTTPプロトコル経由でNTLM認証(マン・イン・ザ・ミドル)攻撃を行います。ネットワークパケットをコントロールするパターンの場合、SMBプロトコルを使って同じことをやります。

どちらも、マン・イン・ザ・ミドル攻撃を完了した後、Domain ControllerのLDAP認証に中継します。

3.Exchange Serverのコンピューターアカウントに、過剰な権限が割り振られている

脆弱性、というよりは仕様上の欠点ですが、Exchange Server(のコンピューターアカウント)はActiveDirectoryに対して非常に強い権限を持っていまづ。これにより、1と2の方法でExchange Serverのコンピューターアカウントを乗っ取り、Domain Controllerに対して認証を成功させることで、ActiveDirectoryに対して自由に操作が出来てしまう状況です。

アタック方法

Githubで公開されている簡単なスクリプトを利用すればいけそうです。

GitHub – dirkjanm/PrivExchange: Exchange your privileges for Domain Admin privs by abusing Exchange

影響をうける環境

この脆弱性を利用してADを乗っ取るには

  • Exchange ユーザーのID/Passwordを知っている事
  • Exchange Serverに対してEWSアクセスできるネットワーク環境にいること
  • ActiveDirectoryに対してNTLMアクセス可能なネットワーク環境にいること

が必要です。また、

  • NTLMv1が有効であること

が条件のように思われます(元記事の”The technical bits – relaying to LDAP and signing”によると、NTLMv2ならMICと呼ばれるハッシュ値を改ざんできず、マン・イン・ザ・ミドル攻撃が失敗する)

悪意のある社外ユーザーに攻撃されるか?

  • Exchange ユーザーのID/Passwordを知っている事
    • 通常は知りえないが、漏洩したID/Passwordを知られている可能性があるので、危険性あり
  • Exchange Serverに対してEWSアクセスできるネットワーク環境にいること
    • 外部からのEWSアクセスを許可している場合があるので、その場合は危険
  • ActiveDirectoryに対してNTLMアクセス可能なネットワーク環境にいること
    • ADを外部に公開しているケースは少ないと思われる。攻撃者がADに接続できなければセーフ。

ADにアクセスさえできなければ、ADを乗っ取られる可能性はないです。それでもExchange Serverへの攻撃は通ってしまいますが…。あるいは、EWSを外部公開していないとかだと安心です。

悪意ある社内ユーザーに攻撃されるか

一般的な社内ユーザーは上記条件を満たしているので、簡単に攻撃が出来ます。

対処法(案)とそれによる影響

マイクロソフト社から正式な修正パッチが出るまでは、解説記事で触れられている方法で対応するしかなさそうです。しかしながら、一部対応はマイクロソフト社非推奨の内容であり。実行にはリスクが伴うものもあります。

対処法1. EWSの機能を制限

EWSにさえアクセスできない/使えないならこの攻撃は成立しないので、EWSを無効化、あるいは以下のコマンドで、EWSのpushsubscriptionsを無効化することができます。

New-ThrottlingPolicy -Name NoEWSSubscription -ThrottlingPolicyScope Organization -EwsMaxSubscriptions 0
Restart-WebAppPool -Name MSExchangeServicesAppPool

本対処方法はマイクロソフトが推奨するものではなく、EWSの動作に必要な機能まで無効化される可能性があります。

対処法2. LDAP Channel bindingの有効化、SMB署名の有効化

LDAP Channel bindingの有効化またはSMB署名の有効化を行うと、それぞれのプロトコルで改竄が出来なくなるようです。

SMBを防いでもEWSに対してHTTPアクセスし、NTMLへのマン・イン・ザ・ミドル攻撃をすればLDAP認証までたどり着けるので、根本解決はLDAP Channel bindingかと思われます。

対処法3. Exchange Serverのコンピューターアカウントから、過剰に付与されている権限をはく奪

Githubに公開されているツールを利用して、Exchange Serverのコンピューターアカウントから、過剰に付与されている権限をはく奪することができます。

使い方は以下記事の中盤を参照

Import-Module ServerManager
Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
.\Fix-DomainObjectDACL.ps1

で、現状の危険な権限を列挙し

.\Fix-DomainObjectDACL.ps1 -Fix

で修正を行えます。

本対処方法はマイクロソフトが推奨するものではなく、Exchange Serverの動作に必要な権限まではく奪する可能性があります。

対処法4. NTLMv1プロトコルの無効化

元記事を読む限り”NTLMv1プロトコルの無効化すれば解決じゃね?”と思うのですが、元記事の解決策には書いておらず、NTLMv1の無効化が正しいかどうか不明です。

マイクロソフト社の動き

2019/1/31では公式声明はないですが、MSとつながりの深い海外のエンジニアいわく、マイクロソフトが解決のために動いているとのことですが、公式ソースは出ていません。

Serious Exchange Server vulnerability reported

But, before going any further – Microsoft is actively working to resolve the issue as quickly as possible, so expect to hear more from the Exchange team in the coming days.

Invoke-RestmethodでGraphAPIを叩くと2バイト文字が文字化けする

自分の知識不足ですが、ハマる人いるかもしれないのでメモ。

Office 365のGraphAPIを利用し、Office 365 の利用状況レポートをダウンロードする事が可能です。Flowでやる手順は前に記事に書きました。

GraphAPI経由でのOffice 365 レポートをFlowで取得する

これをpowershellで実行する事もできます。こんな感じです。

$url = "https://login.microsoftonline.com/[テナントID]/oauth2/token"

$body = @{
    "grant_type" = 'client_credentials'
    "resource" = "https://graph.microsoft.com"
    "client_id" = '[クライアントID]'
    "client_secret" = '[シークレットキー]'
}

$ContentType = "application/x-www-form-urlencoded"
$oauth = Invoke-RestMethod -uri $url -Method post -header $header -Body $body -ContentType $ContentType

function AccessGraph ($url, $filename) {
    $headerParams  = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}
    $ContentType = "application/octet-stream"
    $res = Invoke-RestMethod -uri $url -Method Get -header $headerParams -Body $body
    $res | out-file $filename -enc utf8
}

$url = "https://graph.microsoft.com/v1.0/reports/getEmailAppUsageUserDetail(period='D7')"
$filename = "getEmailAppUsageUserDetail_period.csv"
AccessGraph $url $filename

しかしながら、このコードでは出力結果が以下のようになります。

先頭にUTF-8のBOMが表示され、中盤に表示されるはずの氏名を表す2バイト文字は文字化けています。この文字コードはUTF-8であり、スクリプト自体の文字コードや出力形式もUTF-8のはずですが…なんでや!

解決策

Invoke-RestMethodのオプションパラメーターである、-OutFileを利用すれば文字化けしない。

・修正前


    $res = Invoke-RestMethod -uri $url -Method Get -header $headerParams -Body $body
    $res | out-file $filename -enc utf8

・修正後


    Invoke-RestMethod -uri $url -Method Get -header $headerParams -Body $body -OutFile output.csv

なるほど。おそらくですが、修正前のコードだと、一度 $res という関数に格納した時点で文字コードがおかしくなってしまうようです(WindowsOSのせいかも?)

修正前のコードは、ひとまず $res 変数に突っ込んだ後、いろいろと処理ができるようにする、私が良く使うコードなのですが、コマンドレット純正のアウトプットメソッドを使う事で解決する場合もある、という事を学ぶ事ができました。

vscodeの利用に必須な”ワークスペース”の概念

背景

node.jpを触ってみようと思いました。そして折角なのでvscodeで開発しようと思いましたが、vscodeの事をあまり分かってなかったのでこの機会に勉強しました。なお私はバッチファイルなどしか書けないエンジニアで、モダン開発の知識は皆無です。このエントリは自分用のメモで特にみなさんに新しい知識を提供できるものではありません。

vscodeとは

MS製のソースコードエディタ。人気

Visual Studio Code – Code Editing. Redefined

従来型のテキストエディタとの違い

さて、私は旧来からのサクラエディタ使いである。

サクラエディタ

結論から言うと、秀丸やterapad、notepad++など、従来のテキストエディタを使い慣れていた人が最近のソースコードエディタを使う場合、考え方を変える必要がある。テキストエディタの延長線上にあり、テキストエディタよりもいろいろ出来るツール、と考えると上手く使えない。

環境設定の考え方:ワークスペースの概念

従来のテキストエディタの場合、例えばシンタックスハイライトや文字の折り返し設定などは、ファイルの拡張子単位で環境設定を行っていた。

しかしソースコードエディタではディレクトリ単位での環境設定となる。

具体的には違う拡張子のファイルでも同じワークスペースの設定であれば、同じ設定で動作させることが出来る。何がメリットか?例えばpython用のワークスペースとjavascript用のワークスペースでは設定を変えた方がよいときもあるし、ブログ用にテキストをがしがし書くワークスペースでは日本語の読みやすいフォントで表示したい、といったことを実現できる。

ワークスペースの概念とはつまりはプロジェクトの考え方である。1つのソフトウェアを開発するにあたって必要な定義ファイルやモジュールなどを1まとめにプロジェクトとして定義し、gitで変更管理などを行う。開発の世界では普通の考え方のようだが、シェルスクリプトしか書いていないインフラエンジニア上がりに取っては不慣れな概念であった。

つまりvscodeの環境設定の神髄は1にワークスペース、2にワークスペース、3、4、5もワークスペースである。

なお、ワークスペースには複数のフォルダを束ねることが出来る。それについては以下で説明していく。

vscodeの設定構造

以下のような構造となる。

vscodeは4つの設定定義レベルが存在する。

  1. vscode全体の設定(プログラム規定値)
  2. vscode全体の設定
  3. ワークスペース単位の設定
  4. フォルダ単位の設定

「vscode全体の設定(プログラム規定値)」と「vscode全体の設定」を便宜上違うものとして扱っているのは、vscode全体の設定(プログラム規定値)はプログラム内部に組み込まれており、カスタマイズしたvscode全体の設定だけが設定ファイルとして表現されるためであり、どちらも設定のスコープはvscode全体にかかる。

ご想像の通り、設定の優先度は「vscode全体」が一番弱く、「フォルダ単位」が一番強い。例えば、vscode全体で白ベースの色設定を行っていたとしても、ワークスペース単位で黒ベースの色設定を行っている場合、それが優先される。

それぞれの設定ファイルの場所は以下。

名称 パス ファイル名
vscode全体のユーザー設定(規定値) なし なし
vscode全体のユーザー設定 C:\Users\keisuke\AppData\Roaming\Code\User settings.json
ワークスペースのユーザー設定 任意の場所 [ファイル名].code-workspace内のsettings.json
フォルダ単位のユーザー設定 フォルダ.vscode settings.json

vscode全体のユーザー設定

ファイル -> ユーザー設定 -> 設定より、vscode全体のユーザー設定が可能である。具体的にはフォントサイズやエディタの配色テーマを設定できる。

仕組みとしては、規定値がプログラムに組み込まれており、設定を変更した内容がsettings.jsonに追記される。

C:\Users[プロファイル名]]\AppData\Roaming\Code\User\settings.json

“ワークスペース”の概念

ワークスペースにはフォルダを指定可能であり、複数のフォルダを指定する事も出来る。規定ではワークスペースは作成されないので、明示的に作成する必要がある。作成してもしなくてもいい、と考えるのは間違いで、vscodeを効率的に使うためには作成必須である(ここがテキストエディタ文化になれたユーザーがハマりやすい部分)。ワークスペースとするフォルダを指定したら、ワークスペースを保存する。すると、[ファイル名].code-workspace というワークスペース定義ファイルが生成される。内容は以下の通りある。

ここでは、ワークスペースファイルから見て自分自身のフォルダと、C:\script~という2つフォルダが1つのワークスペースに定義されている。

ワークスペース用のユーザー定義

ワークスペースを定義する事で、vscode全体のユーザー設定を上書きするワークスペース用のユーザー設定を定義できるようになる。例えば、vscode全体の配色テーマは白だが、ワークスペース用のユーザー設定で黒と定義した場合、そのワークスペースで作業する際は配色テーマが黒になる。

ワークスペース用のユーザー設定を実施した場合、ワークスペース用のユーザー定義ファイルである[ファイル名].code-workspace内のsettings.json内に設定が記載される。

※ 上記の赤枠部分

フォルダ用のユーザー定義

同じ考え方で、vscode全体のユーザー設定、ワークスペース用のユーザー設定を上書きする、フォルダ用のユーザー設定が可能である。ただしフォルダ用のユーザー設定はvscode全体やワークスペースと比べて限定的であり、配色テーマの変更などは出来ない。

フォルダ用のユーザー定義は、各フォルダの.vscode\settings.jsonに保存される。

ここまでのまとめ

さて、これでワークスペースの概念と、vscodeの設定構造が分かったが、具体的にこれらをどう使えばいいか。私の考えでは…

  • vscode全体設定は基本的に規定値
  • powershell用、javascript用、テキスト用など、用途に分けてワークスペース設定を行う
  • フォルダ単位の設定は利用しない

である。結局大事なのはpowershell用、javascript用、ブログ用テキスト用など、用途に分けてワークスペース設定を行う事である。例えば、javascript用ならWebにUPするので、文字コードはUTF-8、改行はLFの方が都合がよいが、powershellでActiveDirectoryから値を取り出して保存してExcelで開きたいなら、文字コードはSJIS、改行はCR+LFがよい。

フォルダ単位の設定を利用しない理由は、正直用途がよく分からないからだ。この後、勉強を進めていくことで利用シーンに気づくかもしれないが、今は利用しないでおく。

誰も知らないMicrosoft LauncherとOffice 365 EM+Sの関係

前書き

Office 365 アドベントカレンダー、12月12日です。実はアドベントカレンダー用にForms/Flow/GraphAPIのエントリを書いていたのですが話題がかぶってそうなので、Androidスマホ用Microsoft製のMicrosoft Launcherの話をします。誰得?

※ Forms/Flow/GraphAPIのエントリはこちら

そもそも”ランチャー”とは

簡単に言うと、Androidスマホの”外観”を表現しているソフトです。昔、WindowsXP時代に、explorer.exeを入れ替えることでWindowsをLinux風にしたりMac風にしたり、といったことがはやりましたが、ああいうことが出来ます。iPhoneの場合、ジェイルブレイクしない限りiPhone固定のあの外観となりますが、Androidの場合はランチャーを変更することで同じスマホでも全く別の外観に変更できます。

以下、Microsoft LauncherのGoogle Play のアプリの画面ショットです。

デフォルトのランチャーから変更するメリットは?

理由その1. メーカー純正のランチャー使いづらいから

昔のNECのPCのように(名指しごめん)、デスクトップにメーカー製の余計なソフトが表示されてしまうように、AndroidもメーカーによってはXperiaなんとかソフト、みたいに普段自分が使わないソフトが場所をとっちゃってる場合がある。これをランチャーを変更し、クリーンな状態から自分好みのデスクトップを作ることが出来ます。

以下、懐かしのNEC製WindowsXP(邪魔なアイコンを削除したい – 日経トレンディネットより)

以下は、富士通製スマホに搭載されている富士通純正のランチャー。アイコンが大きく使いやすいが、スマートでない印象を受ける(ホーム画面の設定をする | 富士通 arrows M02 | BBIQ接続・設定マニュアル)より。総じて、3rdパーティーの作るランチャーの方がクールで多機能、といった印象です。

理由その2. スマホメーカーを乗り換えても同じ外観で操作できる

例えば、Xperiaを使っていてXperiaのランチャーに慣れてしまった場合、Huaweiスマホに乗り換えるとHuawei製のランチャーになります。もちろんこれにXperiaのランチャーをインストールすることもできるのですが、Xperiaのランチャー = SONY製のソフトが裏でインストールされている前提なので、無理やりHuaweiにインストールしてもセットアップが面倒。

こういう理由で3rdパーティーのランチャーを利用したほうが利便性が高まるし、メーカーロックインも避けれてよいと思います。

Androidで有力なランチャーソフト

ランキングを見てみたところ、以下の4つあたりが有名なようです。右側の数字はダウンロード数。

私はNova Lanucherの有料ユーザーでしたが、Microsoft信者なのでMicrosoft Launcherの存在を知って 速攻乗り換えました(真の信者ならWindows Phone使え!という声は無視)

ともかく、Microsoft LauncherはAndroidランチャーソフトの中でそこそこの知名度のようです。他のランチャーが無料版と有料版で格差があるのに対して、Microsoft LauncherはMicrosoftの戦略製品であり、すべての機能が無料でそこそこ多機能なのがよいかもしれませんね。

Microsoft Launcherでできること

外観の変更系などランチャーとしての基本機能に加えて、Microsoft Launcherでは、ランチャー自体にOffice 365 のアカウントを登録し、連携することができます。具体的には…

その1. Exchange Onlineの予定表が表示される

連携したOffice 365アカウントの、Exchange Online メールボックスの予定表に登録している予定を、

  • 予定の開催時刻
  • 予定の件名

まで表示できるようです。なお、表示期間は当日~1週間となります。

その2. Windows 10 のタイムライン連携ができる

Windows 10に”タイムライン”という、起動したアプリケーションや開いたファイルが記録できる機能があります。この機能が、Androidスマートフォン上でも使用できるようです。よって、仕事用のWindows10でSharePoint上のExcelファイルを開くと、その履歴がAndroidにも同期され、Androidのタイムラインでクリックするだけで同じファイルを開くことができます。

EM+Sを用いたMicrosoft Launcherの制御方法

情シス視点で私用端末からのOffice 365へのアクセスを防ぎたい場合、アクセス元がMicrosoft Launcherである場合の制御を考えます。使うのはもちろんEM+Sライセンスで利用できるAAD条件付きアクセスです。

AAD条件付きアクセスルールをMicrosoft Launcherに合致させる

結論から言うと、Microsoft Launcherを制御するためには、Exchange Onlineサービスに対して条件付きアクセスを書ければよいです。理由はEM+Sの制御ルールとして、特定のアプリが触りに行くサービスのうち、一番厳しい条件付きアクセスルールが適用されるということです。Microsoft Launcherは現状、

  1. Exchange Onlineの予定表
  2. Windows 10のタイムライン

の2つを表示します。1.はExchange Onlineサービスなので、Exchange Onlineに対する制御をかければいいです。Win10のタイムラインはDelveか何かに保存されているのかな…と思うので、もしかしてDelveに対して制御をかけても効くかもしれないですね。

動作確認

EM+Sの試用版テナントを契約し、テスト用のユーザー”emsuser”を作成します。以下のように条件付きアクセスを構成します。

  • ユーザーとグループ:emsuser
  • クラウドアプリ:Exchange Online
  • 条件:デバイス プラットフォーム -> 全てのプラットフォーム
  • アクセス許可:アクセス権の付与 -> 多要素認証を要求する

PCからの確認

試しにPCのブラウザからログインして、多要素認証がかかることを確かめます。

Microsoft Launcherからの確認

この状態でMicrosoft Launcherからアカウントを登録します。

ID/Passwordを入力すると…。

多要素認証が動作します。

スマホに届いたSMSを登録すると、Microsoft Launcherへのアカウント登録が完了します。

Exchnage Onlineの予定も表示されました。

Azure AD のサインインログを確認すると、

  • アプリケーション:Microsoft Launcher
  • クライアントアプリ:Mobile Apps and Desktop clients

と表示があります。

ブラウザはChrome mobileのようです。

ということで、Exchange Onlineに対してしっかりと条件付きアクセスを設計している環境であれば、Microsoft Launcherに対しても同等のポリシーが適用される仕様となります。

余談

Microsoft LauncherでOffice 365 アカウントを登録すると、Androidシステムの”仕事用アカウント”に設定が保存されるようです。で、仕様かどうかわかりませんが、Microsoft Launcherではアカウントを登録することができるが削除することはできず。Androidシステムの”仕事用アカウント”設定から削除する必要があります。

また、Androidシステムの”仕事用アカウント”の仕様だと思いますが、Office 365上でパスワードを変更しても、再認証が求められません。Windows版のOneDriveのような感覚でしょうが、OSに何らかの認証キャッシュを持って初回設定後は何があっても再認証が不要となるようです。

EM+Sがない場合

注意:ここからマニアックな話に入ります。

EM+Sを買うカネはない!けどMicrosoft Launcherなんて知らなかった!私用端末で予定表が見れるのはまずい!禁止しよう!…と決めたとします。ここで勘違いしやすいのがExchange Onlineの設計でよくやる外部との予定表共有禁止と、Microsoft Launcherで予定表の閲覧を不可とすることは全く関連性がないということです。

外部との予定表共有を禁止するためのExchange Online で共有ポリシーについてはこちら。

Exchange Online で共有ポリシーを作成する | Microsoft Docs

用途としては、自分の仕事の予定を外部、例えば取引先や家族と共有したい、というものですが、日本企業では許可されたドメイン以外は共有禁止になっている所が多いと思います。この機能は、自分の予定を他人に共有するかどうかの制御ですが、Microsoft Launcherは、自分のID/Passwordで自分の予定表を見ているだけなので、無関係です。

ではどうやって制御するか?

ユーザーの利用できるプロトコルでの制御

結論から言うと制御できないようです。

以下、テストユーザーのプロトコルをできるだけdisableに。

この状態でも無事に予定表が表示できてしまいました。

よって別の方法を考えます。

Exchange Onilne クライアントアクセスルールの利用

素人にはお勧めできないNew-ClientAccessRuleを使います。結論から言うと、ブロックできました。

Exchange Online クライアントアクセスルールでは、Set-Casmailboxで設定できるものより詳細なプロトコルベースでアクセス制御が可能であり、以下の12通りのプロトコルが指定できます。

  • ExchangeActiveSync
  • ExchangeAdminCenter
  • ExchangeWebServices
  • IMAP4
  • OfflineAddressBook
  • OutlookAnywhere
  • OutlookWebApp
  • POP3
  • PowerShellWebServices
  • RemotePowerShell
  • REST
  • UniversalOutlook

これを怪しい順にブロックしていくと…

なんと、RESTを追加した時点で、予定表が見えなくなってしまいました。これは予想外。

ただ、OutlookクライアントがMAPIベースでなくRESTベースで作り変えられる、という話もあるので、今後は本格的にアクセスプロトコルがRESTに集約されていくのかもしれないですね。「Microsoft launcherのアクセスを防ぐためにはRESTとかいうのをブロックすればいい!」をやるといろいろと終わるの後注意ください。

なお、このアクセス制御はExchange Onlineに対するアクセス制御となるので、Microsoft Launcherに対するOffice 365アカウント登録・ログイン自体はうまくいきます。

図解するとこんな感じです。

ということで誰が望んでいるかわかりませんが、Microsoft Launcherの仕様が分かったのですっきりとしたクリスマスを迎えられそうです!!!!!ほんとこれ誰得だよ…。

※ 真面目にAndoridを管理する場合は、本日公式から出た以下の記事をご確認ください。

How does Microsoft Intune transform Android enterprise management? Let me count the ways – Microsoft Tech Community – 299289

オーナーなしTeamsをメンバー自身に救出させる~Forms/Flow/GraphAPIを利用し、無駄な管理者運用を削減する~

このエントリでは、オーナーなしTeamsのメンバーがFormsから問い合わせをすると、条件を満たした場合、自動的に問い合わせたメンバーをオーナーに昇格させる仕組みの作成方法を記載します。

が、本当に伝えたいのは

Forms/Flow/GraphAPIを組み合わせることで管理者権限の一部だけをユーザーに切り出し、既存の管理者作業が自動化でき、管理者もユーザーもハッピーになれる!

ということです。今回のフロー以外にも…

  • メールが着信しているか確認するための、メールログの検索
  • SharePointライブラリの容量拡張
  • メーリングリストへの社内メンバー追加

といった、判断が単純で例外が少ない作業は、容易に置き換え可能と思われます。

今回作成するフロー

こちら。

Forms/Flow/GraphAPIを組み合わせることで、ユーザーからのインプットを元に判定を行い、自動で処理が行われるようにできます。

作成したフローのソース

githubに置いておきました。

teraco/rescue-noowner-teams

このエントリ、画面ショット中心で画面の中の文字列は画像のままなので詳細パラメーターコピペしたい!という場合は、githubのソースをご確認ください。めんどくさがりやですいません。なおこのエントリの画像もgithubのソースもテストテナントのテナントIDやアプリケーションIDが入っていますが、自分のものに置き換えて利用してください。

※ テストに使用したアプリケーションは既に無効化されています。

Forms/Flow全体像

フロー全体像です。次のスライドからセクション毎に説明します。

1.Formsの作成

チーム名だけを入力可能なFormsを作成します。シンプルですね。

2. Formsの値読み取り

ひとまず上記Flowで入力された値と裏で送信されているユーザーIDなどを読み取ります。あと、後半で使う変数もここで定義しています。

Apply to eachは勝手に作られますので、ひとまず上から順番にFlowを作っていきましょう。

3-1. ユーザー所属Teams読取り

Formsでユーザーが申請したチームにユーザーが実際に所属していることを確認します。そのために、ユーザーが所属しているTeamsの一覧を取得します。

List joinedTeamsは先日GAされたTeams関係のAPIです。で、ポイントですが、List joinedTeamsのユーザー指定がユーザーオブジェクトIDしか受け付けずUPNが使えない事です(これで2日ほどハマりました)。

よって前段でGet a userしてユーザーのユーザーオブジェクトIDを特定してからjoinedTeams実行してます。

3-2. 処理対象Teams特定

ユーザー所属Teamsと、Formsに入力されたTeamsの名前が一致していることを確認します。ここは普通のif文。

4-1. グループオーナー有無確認

ユーザーが申請したTeamsにユーザーが所属していることは確認できましたので、実際にそのグループのオーナーが0人であることを確認します。オーナーが存在する場合、管理されているTeamsであり、ユーザーが勝手にオーナーに昇格しようとしている、ということですので…。

4-2. グループオーナー昇格

条件を満たしたので、申請者をグループオーナーに昇格させます。

動かしてみましょう

所有者が0人になったチームが存在します。

ユーザーがFormsから申請します。

申請者が所有者になります。

出来上がった業務フロー

before

after

ということで情シスの介入が不要となりました。

まとめ

こまごまとしたユーザー問い合わせに対して、ほぼ判断なく事務的に実行している情シス業務をForms/Flow/GraphAPIに肩代わりさせて楽になりましょう!

おまけ

Flow vs LogicApps

上記の処理はFlowではなくLogicAppsでも実装できます。ではどちらがよいか?

  • マイクロソフト社の推奨
    • Flowはユーザー自身がユーザーの仕事を便利にするための個人的なツール、LogicAppsは情シスが組織全体に使わせるフローを作るための物
  • 現実
    • 機能差
      • Flowはスマホ用のボタンをトリガーとできたりするが、それ以外ではLogicAppsの方が多機能
      • 逆に言うとFlowで間に合う機能で実現できるならFlowでよい
    • 課金体系
      • FlowライセンスはOffice 365に含まれており、一定回数以下の実行なら無料
      • LogicAppsはステップあたりの課金であり、1回の実行から課金されます。

よって手軽に使えて機能的にもLogicAppsに比べて遜色のないFlowがよく使われていた印象です。

しかしながら、2019年2月1日からHTTPコネクタを利用するためには、Office 365 のFlowライセンスではなく、Flowの有料ライセンスが必要となり、FlowとLogicAppsの機能差が広がります。

※ このエントリのフローもLogicAppsかFlowの有料ライセンスがないと実現できなくなりました。

Updates to Microsoft Flow and PowerApps for Office 365 – Microsoft Tech Community – 289589

今後もこのような流れが続きFlowとLogicAppsの機能差が拡大するならば、組織全体で動作を保証しなければいけないものはLogicAppsで作るのがよいかもしれません。

Flowをもっとうまく書く

先日、太田さんがツイートしていたigniteのFlowセッション動画がお役立ちです。

Microsoft Flow and PowerApps: Advanced workflow and business process management – BRK2230 – YouTube

13:58くらいから解説があるのですが、今回のフローのようにifのネストが発生する場合にそれを避ける方法など、実用的なテクニックが記載されています。

前述の通り、FlowではなくLogicAppsを使う場合、課金体系がステップ毎になるので、少ないステップでLogicAppsを実装することがお金に直結します。ので頭を使ってパズルを解くようにLogicAppsを作る必要があります。非常に楽しそうですね!

その他各種テクニック(メモ)

GraphAPIアプリケーション登録方法

こちらに全てが書かれています。

Microsoft Flow の HTTP アクションにある Active Directory OAuth 認証で Microsoft Graph API を利用する | idea.toString();

2018年12月現在、「アプリ登録」と「アプリ登録(プレビュー)」があり、登録手順が若干違いますが…。アプリ登録の概念を理解すれば登録できるはず…です。

JSONスキーマの確認

Flowで実際に流して確認してもいいが、GraphAPIでAPIをたたき、戻ってくる値を確認するのが一番容易。慣れている人はPostmanやPowerShellを使用可能。

JSONスキーマがエラーになる

上記の方法で自動認識させると厳密な型判定を行うので、実際に流してみてNull値があった時にエラーとなる。型指定を解除するか、使用しない項目なら単純削除すればOK。