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。

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

第23回 Office 365 勉強会で発表した内容の続きです。発表した内容はこちら。

このブログエントリではFlowによる情報収集を説明します。

  • GraphAPI経由でのレポートが一番有用だが、レポート取得するのにひと手間かかる
  • Flowで取得する事で、日次データ取得が簡易になる

作業1. アプリケーション登録

Azure AD Portalからアプリケーションを登録し、GraphAPI経由でデータを取る準備をします。手順は割愛…。リファレンスの通り、レポートを取得する際はReports.Read.All権限でOKです。

作業2. Flowでの取得

本題。レポート取得のためのFlowを作成します。

1. GraphAPIにアクセス

URI欄に取得対象のGraphAPIのURLを入力します。FlowでHTTPリクエストアクションを追加し、Active Directory Oauthを選択。作業1. で登録したアプリケーションの情報を登録します。

2. 戻り値の解析
  1. で指定したAPIの戻り値がJSON形式となるので解析します。スキーマはこちら。

{
“type”: “object”,
“properties”: {
“Transfer-Encoding”: {
“type”: “string”
},
“request-id”: {
“type”: “string”
},
“client-request-id”: {
“type”: “string”
},
“x-ms-ags-diagnostic”: {
“type”: “string”
},
“Duratio”: {
“type”: “string”
},
“Strict-Transport-Security”: {
“type”: “string”
},
“Cache-Control”: {
“type”: “string”
},
“Date”: {
“type”: “string”
},
“Location”: {
“type”: “string”
},
“Content-Type”: {
“type”: “string”
},
“Content-Length”: {
“type”: “string”
}
}
}

自分で調べるときは、GraphAPIのリファレンスを見る、GraphExplorerから動かしてみる(一番かんたん、おすすめ)、ひとまずFlowでGraphAPIをたたいて戻り値を全部確認するなどの方法があります。

3. 実データにアクセス

戻り値内にあるLocationに実データへのアクセスURLが記載されているので、HTTPアクセスを行います。

4. Flow実行条件の修正

“OAuth認証してトークン取得”のHTTPステータスコードは302だが、Flowの仕様としてエラー扱いとなるので、エラーでも次のステップを実行するよう設定を変更します。

GraphAPIの仕様上、データへのアクセスを試み、認証が成功した場合、直接データはダウンロードできず、HTTPステータスコード302とともに“データがダウンロード可能な一時的なURL”が生成される。PowerShellやPostman、ブラウザは302に対応して自動的にリダイレクトされるが、Flowはしていないため、今回のような手順を作成している。

5. 動作確認

Flowで設定した定期的なスケジュールでユーザーデータのダウンロードが可能となりました。

参考にしたページ

Monthly Office 365 Update (2018年9月分,10月分,11月分)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。ブログタイトルはMonthlyですが例によって3か月分。8月からやってないので微妙なんですけど、継続は力なので。

チェックソース

メッセージセンター

MC147699 New features: Outlook for Windows user experience updates and Coming Soon preview pane

Outlook for Windowsでリリース予定の新機能をユーザーが試用できる機能。私の環境では先日有効になってました。

MC147874 New feature: Insight Services in Excel (Win32) / MC149159 New feature: Ideas in Excel and PowerPoint Online

ってのが有効になるようです。設定を行う事でOFFにできる…ようですが、記事を見た感じだと、ONのままでも問題ないような気がしますね。インターネットに情報を取りに行ってしまうので、エンタープライズ要件では嫌がられる可能性がありますが。

MC149276 Outlook for Windows now blocks external content in S/MIME messages by default

S/MIME署名付きメッセージに含まれる外部コンテンツをブロックするようにする。例えば、悪意のある画像やコンテンツへのリンクが張られた場合でも表示してしまっていたわけで、本来こういう動作になるべきで、バグ修正との位置づけです。業務上困る場合は、レジストリ設定で回避できる様子。S/MIME署名付きメッセージとかそんなに見かけないですけどね…。

MC149826 We’re updating the look of Office 365 desktop apps

ProPlusのリボンアイコンが変わるやつ。私は新しいデザインが好きです。

MC150492 Reminder: We’re extending coverage of enhanced anti-spoofing protection to all Exchange Online organizations

ATPの一部の機能がEOPしか使えない顧客にも降りてくる話。以前このブログでも話題に上げました。

ATP AntiSpoofingについて

MC152260 Updated feature: portal.office.com/myapps migrating to the Office 365 gallery

個人用アプリが廃止され、Office 365 Galleryが正になる、という話。SIer的には、AADP案件の動作確認で個人用アプリにアクセス出来る事、というテストケースがあるので、それがこれからはOffice 365 Galleryになるくらいでしょうか。

MC152261 Reminder: Support for TLS 1.0 and 1.1 in Office 365

TLS 1.0,1.1のサポート廃止するよ、というリマインダー。当初はTLS 1.0,1.1をブロックするという話でしたが、MSが日和ってノンサポだけどブロックしないという仕様になったようです。

MC152529 Improving the way we show user’s private OneDrive content in Microsoft Search in SharePoint

SPO使った検索で自分のOneDriveのコンテンツとSharePointの共有コンテンツが分かりやすく表示するよ、という話。

MC152628 Updated: Your users will now receive emails with product training and tips for services in their subscription

Office 365からユーザーに、Office 365 の機能の積極的な利用を促すメールが勝手に配信される様子。MSが製品の利用率を上げたいための施策ですが、管理者側で使わせていない機能の紹介をされるとたまったものではないので、SIer的にはOFFを推奨。

なお、みんなが文句言いまくった結果、リリースが凍結されたらしいです。

MC152814 Microsoft Stream intelligence capabilities available in additional Office 365 plans

Streamの自動字幕機能が、下位のライセンスでも使えるようになる、という話。弊社がE5で普通で使えてたので、他のライセンスで使えないのは知りませんでした。実際に使った結果はこちら。

Teams会議を録画したら自動的にMicrosoft StreamにUPされて、会議で発言した人物を自動検出してくれる機能について

ちょっと期待外れです。

MC152817 New feature: Compliance Control Information Added to Microsoft Secure Score

Microsoft セキュリティスコアにGDPRとかNISTの概念が追加されました。このセキュリティスコアアクションをするとGDPRとかNIST的にナイスですよ~と表示してくれます。よって”全社でGDPR対応するんだ!”って時に使えますね。まぁセキュリティスコアのアクションは可能な限り実行すべきですが。

Enhancing Microsoft Secure Score with Compliance and Service Health Information – Microsoft Tech Community – 280316

MC152952 New feature: New authoring experience for custom sensitive types

全国1,000万人のDLPファンが待ち望んだ、Office 365 へのDLPカスタム定義の追加がサポートされました。今までもPowerShell経由で追加はできたのですが、サポートに聞いてもできるか分からないとか言われるし、自分で追加しても動いているかどうかわからん、ということでかなり怪しい機能でした。今回、GUIからの定義追加がサポートされたから、少しはマシになったのかな。今、一番検証したい機能(だが、顧客ニーズがない)

MC164812 We’re updating presence in Microsoft Teams and Skype for Business

こんなアナウンスあるけど、SfBOとTeamsのプレゼンス、全然リンクしませんわ…。

MC165013 New feature: Scoped Directory Search in Microsoft Teams

Exchange Online のアドレス帳ポリシーに従って、Teamsでコンテンツを探す際のスコープがカスタマイズされる、ということ。正直、ABPをちゃんと設計している会社さんってそこまでいないし、仮に設計していなくてこの機能を知った所でやってみようとう会社は少ないぽいので、現実的に恩恵を受けられる組織は少ないんじゃないかな、と思います。運用大変。

MC165218 Outlook mobile simplifies its sync technology

Outlook for iOS/Androidを使用した時の、Office 365 Exchange Onlineとの同期アーキテクチャが変更になり、より早く、より帯域を食わない形になるそうです。バックエンドの変更なのでわざわざアナウンスするほどでも…と思ったけど、アナウンスするということは何かあるかもしれぬと思い、メモ的に記録。

MC165255 Updated feature: Users can now customize their private discussions in Teams with tabs

プライベートチャット(おそらく、普通のTeamsのチャット)を、チームのタブとして追加できるようになったよ、とのこと。この機能、誰得?とのことですが…。

現在のTeamsの改善要望TOPは”チームの中に、プライベートチャネルを作成できるようにしてくれ”というやつです。具体的には、部のチームを作ったとして、そこの中にマネージャーしか閲覧できないチャネルが欲しい。しかし、現在のTeamsには実装されていないので、別のチームを作成してマネージャーだけそこに召集する、としなければいけません。よってマネージャーは所属チームがめちゃくちゃ増える。

要望TOPなのでとっとと実装すればいいのですが、私の想像ですが、Teamsのアーキテクチャ的に”チームの中に入れ子の権限を実装する”というのが難しいんじゃないでしょうか。仮に可能ならば、すぐに実装していてもよさそうですし。ということで、これがすぐに実装できないので、

  • マネージャー同士でチャットを開始するの
  • そのチャットを、チームのタブに追加する
  • 結果として1つのチーム内でマネージャーだけしか見ることのできない会話ができる

という強引なソリューションな気がします。

Office 365 ATPの適用方法が変更になるかも

こんにちわ。個人的にATPライセンスを購入している変わり者です。最近、ATPのライセンス適用状態に変化があったので分かっている事を書きます。簡単に言うとOffice 365 ATPのライセンスがユーザーに対して明示的に割り当て可能になりそうです。

今まで

  • ATPのライセンスを保有していれば”紳士協定”で利用できた。
  • そもそも、ライセンス割り当て画面にATPが存在せず、物理的に割り当て不能だった。
  • “紳士協定”を守るために、Exchange Online ATPの設定画面より、ATP除外グループを指定して、適切なユーザーがATPを利用できるようにしていた。

現在確認できている事

  • ライセンス付与画面に、「Office 365 ATP」というカテゴリが増えている
  • ユーザーへの割り当て画面にも表示され、ライセンスが割り当てられてない状態である
  • 動作確認を行ったところ、どうやらライセンスを割り当ててなくても、ATPは動いている様子である

これからの予想

  • E3やE5ライセンスと同じく、ユーザーにライセンスを適用する事でATPが利用可能となる
  • ライセンスを付与していない場合、ATPが動作しない

疑問

  • 共有メールボックスなど、無料ライセンスで作成できるリソースに対するATPの割り当て方
  • SharePointなど、複数ユーザーが共有するリソースに対するATPライセンスの考え方はどうなる?
      - 相変わらず紳士協定?

まとめ

ATPは当初、Exchange Online ATPとしてリリースされ、受信メールに対する振る舞い検知として導入されてきました。この時点ではユーザーオブジェクトにライセンスを付与する、という行為は不要であり、ATP管理画面より適用ユーザーを選択する仕様でした。しかしながら、ATPライセンスを持たなくてもATPを使用できてしまう状態であり、よく言えば便利、悪く言えば意図せずライセンス違反を誘発する仕様でした。(E5系の機能もこういうの多いです)

この状態は2,3年?変わらなかったですが、Office 365 ATPと名前が変更され、SharePoint OnlineやTeamsにもATPの範囲が広まったこともあり、適切にライセンスを管理する方針に変更される流れも自然かな、と思います。

現状はMSからアナウンスがない事もあり猶予期間なのか、ライセンスを付与せずともATPが動作する状況です。自分のテナントで、ユーザーにATPライセンスを付与せずとも”Exchange Online ATP 安全なURL機能”が動作する事を確認しました。

ということで今のところ何もしなくても大丈夫そうですが、今後はMSからのアナウンスに注目する必要がありそうです。

画像など

ライセンス画面で「割り当ててください」と表示される。

ユーザー画面を見るとATPが割り当て可能になっており、割り当てられていない状態である。

実際にはATPのsafelinkが動作する。

Global Office 365 Developer Bootcamp 2018 – Japanに行ってきました。

Global Office 365 Developer Bootcamp 2018 – Japan – connpass

です。twitterのまとめはこちら↓

Global Office 365 Developer Bootcamp 2018 – Tokyo, Japan #Office365Dev まとめ – Togetter

LTの資料はこちら(見つかった分だけ)↓

ハンズオンの資料はGlobal Office 365 Developer Bootcamp 2018 – Japan – connpassのリンクからたどれます。

まずは前準備含めたいろいろな調整を行って頂いた運営のみなさま、膨大な資料を分かりやすく説明頂いた登壇者の皆様、みんな面白かったLTの皆様、そして参加者のみなさんありがとうございました。あと会場を無料で貸し出して頂いた日本MSさんと、とんかつプレゼントしてくれた米MSさん!

最高かよ…(もぐもぐ)

私のLTちょい補足

GraphAPIのスロットリング(20181027 office365 developersday)についてしゃべりました。資料以上の事は話してないので詳しくは資料参照なのですが、中にURLをいろいろ埋め込んだのにslideshareじゃリンクに飛べないという事に気づいたので、ここに記載します。

余談ですが、LTが終わった後に同じようにスロットリングに引っかかった経験のある方に声をかけていただき、盛り上がりましたw やっぱりみんな苦労してるんですね…。これについては本当に改善を望みます…。

4つのセッションのイメージと私が選んだセッション

今回は4つのテーマに分かれてのハンズオンでした。つまり4つのうち1つを選ばなければいけません。会場に行くまでの私の心境。

  • テーマ: SharePoint Framework
    • 怖そう…
  • テーマ: Microsoft Graph
    • これやろ!
  • テーマ: Office アドイン
    • 不要ぽい
  • テーマ: Microsoft Teams
    • 一応興味あり

SharePointは、周りに猛者がたくさんいそうなイメージがあるのでちょっと及び腰になっちゃいます。Graphはいろいろと応用がきくのでやってみたい!Office アドオンはまぁ不要ぽいし、Teamsって聞くとひとまず「おっ!」ってなりますよね。

しかしながら、登壇者の皆様のショートセッションを聞いた後の私の心境↓

  • テーマ: SharePoint Framework
    • 凄そう…!
  • テーマ: Microsoft Graph
    • ちょっとローレベル?
  • テーマ: Office アドイン
    • 面白そう!
  • テーマ: Microsoft Teams
    • Ci/CDかぁ~。

SharePointはもう内容からして凄そうな感じがしたので、もう少しSharePointと仲良くなってから取り組みたいかな…。Graphは意外と知ってることが多そう?少なくともGraph Explorerとアプリケーション権限つける部分は知ってるしな~。知らない所もありそうだから聞きたいんだけど。Office アドインは、ダルいマクロの話かと思ってたらWebの仕組みを使って開発できるってことで俄然興味沸いたのと。管理者視点でどういう事が出来るのか、技術的な所を抑えたかったです。Teamsは内容的に面白そうだけど、実際に自分がTeams開発担当になってサービス改善を続けていくことは今の所なさそうかな(ちょっとTeamsアプリ作りたい、とかそのレベルの興味だった)と思いました。

てことで、Office アドインのセッションに参加しました。

Office アドインのセッションについて

めちゃくちゃ良かったです!恥ずかしながら私、Office アドインについては全く知識がなかったのですが、講師のきぬあささんのお話と資料の作りがすごく良くて、「なぁ~るほど!」と唸りながらハンズオンしてました。また、資料の作りがすごく良くて(2回目)ある程度自分で分かってきたらセルフハンズオンでどんどん進めていけます。実際、当日、説明されなかった章もありましたが、私は自分で手順を進めてその部分を進めることが出来ました。

Office アドインのセッションに出ようと思って出れなかった皆さん、本当に資料の作りがすごく良いので(3回目)後からでもよいのでぜひやってみてください。

Office アドインの将来?を考えてみる

今回初めてOffice アドインという存在を知り、仕組みもある程度わかりました。SIer的には、これが今後メジャーになっていくのか?注力したほうがいいのか?とかを考えてしまうのですが…。Office 2013の時は基本的な事しかできず、Office 2016になっていろいろできるようになった、という事もあり、(まだ古いOfficeが多い現状では)いきなり覇権を取る、というのは難しそうです。一方、Office Onlineでも同じように使えるというのはvbマクロにはないメリットだと思います。

最低限、エンタープライズ環境がOffice ProPlusに統一され、基本的にみんな最新のOfficeです、という時代になってからが勝負じゃないでしょうか。

一方、昔ながらのvbaを10年以上も使い続けている現場も知っているので、そういう現場は粘ってこういうのを一生使うかも。昔は、超いけてるvbマクロを無料でホームページで公開している人も多くそれが業務利用されていたりするけど、今は無料公開文化が減って、ビジネスで使えるソフトウェアは何らか収益化を目指すから、そこは昔の無料マクロが強かったり。

きぬあささんがおっしゃっていた通り、今は本屋にExcelマクロ本が並び技術者もたくさんいますが、将来的にマクロ技術者が少なくなり、Officeバージョンも統一され、Webが重視され…といったいろんなファクターが重なりあい、

昔ながらのExcelマクロを使うメリット < Office アドオンを使うメリット

となれば、徐々にOffice アドオンがメジャーになる…かな?あ、けどマクロだけじゃなくRPAとかも競合になるんだよなぁ。

まとめ

凄く価値のあるイベントだったので来年も出たいと思います!