追加費用なしでアクセス制御を実現できる、Exchange Online条件付きアクセス

Office 365 Advent Calendar 2017 - Adventarの7日目です。予定ではExchange Onlineの予定表機能について一言物申そうと思ってましたが、タイムリーにExchange Onlineの新機能が実装されたので嬉しくてテーマ変更します。嬉しい！

Exchange Online 条件付きアクセスとは

MC124248 New feature: Client Access Rules for Exchange Onlineで予告されていたExchange Onlineの新機能です。Azure AD Premium,EM+Sなどの追加ライセンスなしに、Exchange Onlineの設定だけでクライアントからの接続を絞る条件付きアクセスが実現できます。すごいぜ！！！！

Exchange Online のクライアント アクセス規則: Exchange Online Help

できること

以下の条件を組み合わせて、合致した場合に"アクセス許可"または"アクセス禁止"を設定できます。

  • ネットワーク
    • 単体IP：192.168.1.1.
    • IPレンジ：192.168.0.1-192.168.0.254.
    • CIDR形式：192.168.3.1/24.
  • アクセス手法
    • ActiveSync：ExchangeActiveSync
    • Exchange管理センター：ExchangeAdminCenter
    • EWS：ExchangeWebServices
    • IMAP4：IMAP4
    • オフラインアドレス帳：OfflineAddressBook
    • OutlookAnywhere：OutlookAnywhere
    • OWA：OutlookWebApp
    • POP：POP3
    • PowerShellWebServices：PowerShellWebServices
    • Exchange Online PowerShell：RemotePowerShell
    • RESTAPI：REST
  • 認証方式
    • ADFS認証：AdfsAuthentication
    • ベーシック認証：BasicAuthentication
    • 証明書認証：CertificateBasedAuthentication
    • 非ベーシック認証：NonBasicAuthentication
    • Oauth認証：OAuthAuthentication
  • ユーザー属性
    • ユーザー名
    • City
    • Company
    • CountryOrRegion
    • CustomAttribute1-15
    • Department
    • Office
    • PostalCode
    • StateOrProvince
    • StreetAddress

ユーザー属性については、ユーザー名は文字列指定(*によるワイルドカード指定可能、複数指定可能)、その他はOPath形式での指定となります。

やってみる

よくありそうな社外からのOWA使用禁止をやってみました。

1. ルール設定

会社のIPが 163.49.213.44 って想定でルールを作ります。プロトコル指定はOWAで、163.49.213.44以外のネットワークからはDenyとします。

New-ClientAccessRule -Name "BlockOWA" -Action DenyAccess -AnyOfProtocols OutlookWebApp -ExceptAnyOfClientIPAddressesOrRanges 163.49.213.44

ゲットするとこんな感じです。

PS C:\Script> Get-ClientAccessRule | fl


RunspaceId                           : 96ccb8b3-bf62-4c77-8850-c84bc4369e8b
Priority                             : 1
Enabled                              : True
DatacenterAdminsOnly                 : False
Action                               : DenyAccess
AnyOfClientIPAddressesOrRanges       : {}
ExceptAnyOfClientIPAddressesOrRanges : {163.49.213.44}
AnyOfSourceTcpPortNumbers            : {}
ExceptAnyOfSourceTcpPortNumbers      : {}
UsernameMatchesAnyOfPatterns         : {}
ExceptUsernameMatchesAnyOfPatterns   : {}
UserIsMemberOf                       : {}
ExceptUserIsMemberOf                 : {}
AnyOfAuthenticationTypes             : {}
ExceptAnyOfAuthenticationTypes       : {}
AnyOfProtocols                       : {OutlookWebApp}
ExceptAnyOfProtocols                 : {}
UserRecipientFilter                  : 
Scope                                : All
AdminDisplayName                     : 
ExchangeVersion                      : 0.20 (15.0.0.0)
Name                                 : BlockOWA
DistinguishedName                    : CN=BlockOWA,CN=Client Access Rules,CN=Configuration,CN=myalmea.onmicrosoft.com,CN=ConfigurationUnits,DC=JPNPR01A004,DC=PROD,DC=OUTLOO
                                       K,DC=COM
Identity                             : BlockOWA
Guid                                 : 0ae9e5ce-6edb-48e6-bdf8-76d23d08135e
ObjectCategory                       : JPNPR01A004.PROD.OUTLOOK.COM/Configuration/Schema/ms-Exch-Client-Access-Rule
ObjectClass                          : {top, msExchClientAccessRule}
WhenChanged                          : 2017/12/07 23:32:39
WhenCreated                          : 2017/12/07 23:32:39
WhenChangedUTC                       : 2017/12/07 14:32:39
WhenCreatedUTC                       : 2017/12/07 14:32:39
Id                                   : BlockOWA
OriginatingServer                    : KAWPR01A004DC01.JPNPR01A004.PROD.OUTLOOK.COM
IsValid                              : True
ObjectState                          : Changed

2. 動作確認

もちろん実機からも動作確認するんですけど、めっちゃ優れものだな～と思うのは、Test-ClientAccessRuleってコマンドでどのルールが適用されるかシミュレーションできるんですね。(オンプレADのポリシーの結果セット的なやつ)

Test-ClientAccessRule -AuthenticationType BasicAuthentication -Protocol OutlookWebApp -RemoteAddress 163.49.213.44 -RemotePort 443 -User admin@almea.jp
Test-ClientAccessRule -AuthenticationType BasicAuthentication -Protocol OutlookWebApp -RemoteAddress 163.49.213.45 -RemotePort 443 -User admin@almea.jp

Identity Name     Action    
-------- ----     ------    
BlockOWA BlockOWA DenyAccess

1行目は許可したいIPからアクセスしている想定なのでルールがヒットしませんが、2行目は許可IPじゃないので、Denyのルールにヒットしてます。これで許可と拒否ルール間違えて実装とかしても気づくね！

ちなみに最初のルール設定時に"最長24時間かかる事があるよ"って言われて、まっさか～って思ってたらマジで12時間くらいかかったので気長に待ちましょう。2回目からは1時間以内に反映されるようです。

実機からは以下のような画面でブロックされます。

f:id:teraco:20171207235546p:plain

これでAzure AD Premium, EM+S不要じゃない?

一応、EM+Sとの違いをまとめておきますと。

- Exchange Online条件付きアクセス EM+S条件付きアクセス
対象 Exchange Online Office 365,Azure AD 連携アプリ
条件 IP、クライアント種別、認証方式、ユーザー IP、ブラウザまたはアプリ、ユーザー、デバイス
アクション 許可、拒否 許可、拒否、二要素目を求める

デバイス情報での制御、条件に合致したら電話番号などで二要素認証したいならEM+S。逆にExchange OnlineはpowershellやREST APIなど細かい制御が出来るのはよいかも。管理用端末からはpowershellでしかアクセスさせない、とか。

なお、EM+Sの条件付きアクセスと違って、Exchange Online条件付きアクセスでOWAアクセス禁止しても、Teamsその他にはふつーにログインできます。不思議だわ～。

※ EM+S条件付きアクセスでExchange Onlineへのアクセスを禁止すると、Exchange Onlineを基盤としているTeamsへのアクセスも禁止されてしまう

Tips

Exchange Online条件付きアクセスはルールに優先度がつけられ、優先度の高い方から合致したルールが有効になるようです。てことで、管理者IDについてはpowershellを常時許可、みたいなルールを優先度0に入れておくと安全だな、と思いました。

ということで

Exchange Online導入したいけど、ネットカフェからはアクセスさせたくない、ちゃんとVPN張ってアクセスさせたい、というエンタープライズ用途には朗報なんじゃないでしょうか。Exchange Onlineについては、既定の機能でユーザー毎にIMAPやPOPの許可/不許可もコントロールできましたが、Exchange Online条件付きアクセスで一括でポリシーを設定できるのも運用上楽になるかと思います。

逆に言うと、EM+S買ってIP制限しかしない、とかヌルいことやってないで、もっとリッチな機能使おうよ、ってメッセージなんでしょうか。

明日、12/8は@hrfmjpさんです。お楽しみに！

(メモ)PowerShellでSharepoint Online のリストライブラリの分析

Sharepoint Online のリストライブラリの分析をしようと思い、PowerShellでさくっと出来るやろ～と取り掛かったのであった。ググったところ、ドンピシャのエントリが発見できたので…

PowerShell で、SharePoint Online の リストとアイテムの情報を書き出してみた - Qiita

このままコピペ→動作確認完了！後は取りたい列を追加してcsvに吐き出せば終わりやで～ → (To上司)もう取れたも同然です。

SharePoint の列名の取得

上記から1週間後、さくっと列名取得しますか…と思い、 $item | fl で属性全出しを試した所…エラーが(´・ω・`)

コレクションからの列挙中にエラーが発生しました: The collection has not been initialized. It has not been requested or the request has not been executed. It may need to be explicitly requested.。

困ったときはget-member, get-type, flで力押しってExchange Onlineで習ったのに…!!!!

さすがに列名全出しする方法あるやろ…と予想しネットでググるも、記事が見つかるがコマンドが通らない。まさか、オンプレ専用コマンド!?

結局、列名のオリジナルを取得する方法を調べる方向に舵を取り、無事に狙った列名を指定してpowershellでアクセス出来たのでした。

本題

本当はpowershellをAzure Functionで動かしたいんですってことでメモ。今回、サンプルスクリプトで.Netのアセンブリ使っているので、これをAzure Functionにアップロードしなければいけない。その方法はこちら。

Azure Functions: PowerShell Script Interacting with SharePoint Online - Stack Overflow

モジュール配置方法を調べる & 上記の列名特定方法を調べている途中で、"こういうめんどくさいことから解放されるためにGraphAPI使えばええやん"と思いつき、ちょっとだけ触ってみました。Exchange OnlineのGraphAPIは触ったことあるけど、さすがにSPOもあるのね。

ただ、意図した通りには動いてくれず。そこまで深堀しておらず、僕のSPO経験値が少ないからかもしれないので。Channel 9 の動画を見つけたので、時間がある時に見ることにします。

Microsoft Tech Summit 2017の感想など

行ってきました。

Microsoft Tech Summit 2017 | インフラエンジニア、アーキテクト、IT 戦略立案に関わる皆様の為の技術カンファレンス - Microsoft Events & Seminars

場所はウェスティンホテル東京で写真はこんな感じです。写真の腕がしょぼくてすいません。

f:id:teraco:20171109231043j:plain

f:id:teraco:20171108114243j:plain

少し宣伝

今回は、自社のブース展示&対応を行っていました。内容はAzure AD JoinしたWindows 10 PCで、オンプレADにSSOできるというものです。今まで、オンプレADにSSO出来るのはそのADに参加している端末のみ、ワークグループ端末その他は、オンプレファイルサーバーなどにアクセスする際、ID/Passwordを入力するのが常識です。しかしながら、ある条件、具体的にはWindows Hello for Business ハイブリッド構成環境であれば、Azure AD JoinしたPCでオンプレADにシングルサインオンできちゃうんです！！！！すごい！！！！

…というのがあまり実感頂けなかった気がするので、ロジックなどを別のブログ記事で説明したいと思います。ひとまず検索で引っかかるようにキーワードを強調表示しておきます。。。

宣伝はこれくらいにしてセッションの感想です。展示準備のため十分に参加できませんでしたが、聞けたところだけメモします。

DAY1：CLD001：インフラ エンジニアにもできる企業の IT 改革 ～モダンなインフラを作ろう～

途中から入室。少し抽象的なセッションで、意気込み重視というか、技術的な要素は少なかった気がします。

DAY1：PRD012：16万人の「働き方改革」を支えるICT活用 ～社内実践から見えた効果と課題とは～

富士通さんのセッション。使用されている技術に目新しさはないけど、それをどうやって16万人に浸透させるか、という話。新しい技術を振りかざしてお客様を訪問するだけではなく、その技術を実際ユーザーにどうやって使ってもらうかまで意識しないといけないな～と思いました。。新システム導入で一番怖いのは、使い勝手が悪くてユーザーから文句が出るのではなく、導入しても無視され使われない事なんです。

DAY1：SEC001：GDPRと国境無きインターネット

お仕事に影響あるのでちゃんと聞きました。

GDPRという制度について

  • EU域内の国民の個人データを他の国で不適切(適切であっても?)に保管すると罰金。売り上げの4%か26億円。
  • EUは本当に制裁を発動させるので、ちゃんと対応する必要がある。
  • 何かいちゃもんつけられた時に、少なくとも"ちゃんとやってますよ"と説明責任を果たす必要がある。

個人データとは?

  • メールアドレスも個人データ。
  • メールリレーサーバーをメールが通っただけでGDPR対象。個人データの処理が対象だから。
  • IPアドレスやcookieも個人情報である。
  • つまりなんでも個人データと思った方がよい

GDRPの登場人物

  • データ主体⇔管理者⇔処理者
    • データ主体：個人(EUの人たち)
    • 管理者：お客様企業
    • 処理者：MS(SaaS事業者)
  • Q.日本にしか会社ないんだけど?
  • A.日本にしかなくても、EUの人がショッピングサイト使って自分の名前などを登録しており、ショッピングサイトが日本にあればGDPR対象

GDPR有効化における主要な変更点

  • データ主体者の権利を担保する
    • アクセス
    • 修正
    • 消去
    • 意義申し立て
    • エクスポート
  • 制御と通知を確保する
    • データに対するセキュリティ
    • 侵害検出後の72時間以内の当局への通知
    • 同意の取得
    • データ処理の詳細な記録の保持
  • EUのデータを収集するのがダメなのではなく、きちんと管理してますよ、と言えない事が問題である。
  • DPO(Data ProtectionOfficerの選出)はほぼ必須

※ ここらへん、後でスライド補足

EU域外+信頼されている国以外にデータを出すのは原則禁止。EU域外で"信頼されている"国は10数か国で日本は含まれない。

マイクロソフトはどうやってるの?

"世界中のお客様のGDPRへの取り組みをお手伝いします。"具体的なアクションはオンラインサービス条件の中に文言として盛り込む。ひとまず安心してほしい。

…とのこと。

具体的なシステム面からの説明はありませんでしたが、SaaS事業者としては、EUリージョンに建てたIaaSを勝手に他のリージョンに移動しない、という事になるのでしょうか。このセッションを聞いていると、GDPRはSaaS事業者だけの問題ではなく、SaaSを使用する企業自身の問題と感じました。

お客様は何をしないといけないのか??

"ちゃんとやってますよ"というプロセスを作る。例えば、名刺を受領した時…

  • ×よくない例
    • 各人の名刺入れに保管し、捨てたり家に持ち帰ったりポリシーが統一されておらず、トラッキングは出来ない。
  • ○よい例
    • 社内に持ち帰った段階で、名刺管理DBに情報を入れている
    • 各人は必要な時にオンラインで名刺管理DBを参照する
    • 名刺管理DBはIRMがかかっており、社外にコピーできない

など。

感想

EU国民のデータを日本のサーバーで触らない、となると、自社のお問い合わせフォーム用のサーバーをEUに配置して、EU域内のIPからアクセスされた場合、EU内のWebフロントエンドに飛ばしてデータもそこで持つ…としないといけないけど、どんだけシステムコストかかるねん、という話だし、例えばEU国民が日本に旅行に来て日本語でお問い合わせフォームに書いたら、システム上はGDPR対象のデータであると分からない。

それ以前に、仮にEUにEU国民のデータを保管しても、日本の端末から閲覧しただけでブラウザキャッシュが残っちゃうので、結論から言うとシステム的にGDRPを守るのは不可能じゃないかと。

よって落としどころとしては、EU国民のデータも"仕方なく"日本国内のサーバーで処理しちゃうことがあるけど、ちゃ～んと保護するし、ユーザーから申請があれば削除するようなフローを作るし、不要に長期保管しない仕組みを作ってますよ、と言うしかない?

まーしかしskype会議でEUの支店と会話してPPT共有したらどうすんねん、とか考えると辛いね。GDPRの正式施行は2018年5月らしいので、EUの動向に要注目です。

DAY1：SEC002：セキュリティ マニアックスでおます～コネクテッド カー時代に活かす IT サイバー セキュリティ～

途中入室。面白かった～。

  • クルマのハッキングを防御するためには、PCと同じく多層防御の考え方が必要。
  • PCの場合
    • Tier2:クライアントPC
    • Tier1:管理者アカウント
    • Tier0:サーバー
  • のような多層構造となっており、クライアントPCがやられてもそいつを組織から切り離せばOK、など。
  • クルマの場合
    • Tier2:物理ソケット。ここが破られるとチップを入れ替えられて物理的に乗っ取られてしまう。例えばカーシェアなど不特定多数で共有する車はこういった物理的なセキュリティもしっかりしているべき。
    • Tier1:インフォなんとか(名前忘れた)：エンタメ系のモジュール。外部との通信のためにポートが空いていると危険
    • Tier0:駆動系モジュール(名前忘れた)：車に"前進"や"後退"の信号を送るモジュール。本当はここをしっかり守りたいが、このモジュールはCPU性能が低くふるまい検知やアンチウイルスを動かすことが出来ないので、現状、Tier1までで防御する事が重要

クルマ業界も何もやっていないわけではないが、ファームウェアを書き換えられるなどは想定しておらず、IT業界では当然の対策がされていない部分もある。昔からハックに対応してきたIT業界の知見が必要である。

DAY1：SEC005：ネットワーク エンジニア必見！VPN/DMZ は要らなくなる！？ Azure AD Application Proxy で実現するセキュアなアクセス

ネットワークエンジニア向け…なのか?前半、Azure APP Proxyの構築方法。VPNと違って外→内の通信がないからセキュア。内→外の通信。構築時に認証付きプロキシは回避してね。オンプレアプリはAzureポータルからエンタープライズアプリケーションを追加する。理解しやすかったが、レベル400もあるかな…と思いました。

以上がday1。終わった後はBeerBush。写真撮り忘れた...ローストビーフ美味しかったです。

DAY2：DEP008：Microsoft System Centerによる進化したハイブリッドクラウドの環境の管理

System Center RunbookをAzure automationに移行できる、など。個人的にSCCMとIntuneの連携を聞きたくて参加したけどあまり話題なく。System CenterってSCCM以外の機能がたくさんあったの忘れてた僕が悪いですすいません。

DAY2：CLD012：百聞は一見に如かず。デモで理解する Azure Stack の面白さ！

今回のTechSummitの目玉はAzure Stack、ってくらい注目度が高く、セッションも多かったです。このセッションでは利用者からみたAzure Stackと管理者からみたAzure Stackを説明し、最後にAzure Stackのマルチノードの動いている所のデモでした。マルチノードすごい。

事前にちょいと勉強したのですが、Azure Stackって、本当にAzureがオンプレでそのまま使える、以上終了、みたいな所ありますよね。もちろん、負荷分散やネットワーク、冗長化などの構成を考える必要はありますが、それは考えればいいだけで、使う側の使い勝手は変わらない。

ということで、決め手はAzure Stackの使いどころをどのように提案できるか、だと思いました。なんとなく、他のソリューションに比べて営業サイドの人たちが使い方提案で売り込む、Surface HUB的な製品なのかな…と勝手に思ってます。

DAY2：DAL005：Azure Cosmos DB を使った高速分散アプリケーションの設計パターン

同時間帯のハンズオン満席だったのでこちらのセッションに参加。思った以上に面白かったです！CosmosDBは早いしDR組みやすいしよい！けど高いから既存のSQLと役割分担するとよいよ。デモでは軽～く使ってたけど、ドキュメントまじめに読むと1か月かかると言われてビビってます。説明のペースが速かったのでPPTで復習したいと思います。

DAY2：SEC009：Azure AD による Web API の 保護 ～ Azure API Management をセキュリティの観点で解説

Webアプリを使ってAPIを実装し、そのAPIを開発者やユーザーに開放する時に、APIを適切に管理する方法。Azure ADや！って同僚のインフラエンジニアと参加したのですが「そもそも俺たちWebアプリ作ったことある?」とのっけから脱落気味。便利さは一応理解したものの、ちょっと我々には早すぎた…か。ただ、このご時世、アプリ作ったらAPI公開して当然という気もするし、NAVITIMEや駅探のAPIは便利に使わせてもらってます。こういうのをAzure AD基盤で管理できるは知らなかったので勉強になりました。

DAY2：APP003：Azure Functions と Serverless - 概要と企業向け Tips

この時間帯、見たいセッション被ってたんですよね～。Cosmos DBで興味が出たのでAzure Functionへ。これ、全然マークしてなかった自分が恥ずかしく。基本的なサービスのトリガーとバインディングも用意されているから、今までサーバーにスクリプト置いてタスクスケジューラーで動かすシステムを捨てることが出来る。Automationは少し触った事があったのですが、Functionはそれより簡単にデプロイできてびっくりしました。インフラ関係の仕事だと使う機会少なそうだけど、何かの案件で無理やり使ってみたいな～。

DAY2：SEC007：Azure AD B2C と LINE 連携により実現する学校や企業における次世代 ID/メッセージ基盤

期待していただけあってディープでした…。SNSのIDと連携できるAzure AD B2Cだが、標準で連携できるサービスにLINEが入っていない。ならカスタムで作っちゃおう、との事でしたが、ドキュメントがないためほぼ手探り。そりゃ社外秘だわな…。面白いセッションだったけど、これを聞いて"参考になった！自分も解析しよう！"となる人はどれだけいるのか…。なんとも圧倒されるセッションでした。

感想

去年のメモを見返していたのですが。

Microsoft Tech Summit 2016に行ってきたメモ - 今日も元気にIT屋さん

  • 今年増えたもの
    • Azure Stack
    • IoT
    • Serverless
  • 今年減ったもの
    • Exchange/skype
    • MS365製品の単品セッション
    • ID統合系(AADC同期パターンだけの話)
  • 変わらないもの
    • EM+S(ADFSもういらない系の話)

※ あくまで私視点です

個人的にはTeamsがないことが意外でした。EM+S系、Microsoft365系は、おそらく知ってる話だろうな～って出なかったんですがtwitter追ってる感じだと多分予想は当たってたのかな、と。EM+Sの条件付きアクセスについては去年の時点で概念自体は完成していた気もしますが、自分が自社ブースでデモ手伝ってる中でも、まだまだエンドユーザーの情シスまでは浸透していないのかな～?と感じました。キャズム超えそうな雰囲気はあると思うのですが、まだ啓蒙活動が必要だと思います。他は、やはりOffice 365って名前付くとセッション参加人数増えるんだろうけど、Microsoftさんとしてはそういうベーシックなんじゃなく、他の技術をアピールしたいんだろうな～って思ったりしました。

Monthly Office 365 Update (10月分)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。飽きたらやめます。

チェックソース

TechPlusライブラリはMSパートナーじゃないとアクセス出来ないので、いけてる情報があったら内容を紹介する事にします。Office 365 Roadmapは見るの大変なのでやめるかも。結果、Office 365 メッセージセンターだけの紹介に…。

Office 365 メッセージセンター

MC123071 Updated feature: Exchange Online Protection

RFC 5322 に準拠しないメールアドレスはスパム扱いしちゃうぜ！って話らしいです。具体的にはこんなメールアドレスです。

How Office 365 validates the From: address to prevent phishing - Outlook

実際、どの程度スパム判定されるか分かりませんが、11月9日(木)から有効との事で、その日はメールログを要チェックです。

MC123714 New feature: Group insights in Yammer

Yammer上でグループの分析機能が有効になりました。これ、うちにも来ててメンバーだけ多くて活動していないグループも一目でわかっちゃいます…。こういうグラフはコミュニティ運営で励みになりますね。

MC124248 New feature: Client Access Rules for Exchange Online

今まで、Exchange OnlineではMAPIやOWA,POPなどプロトコルレベルでのアクセス制御は出来ましたが、これからは

  • ユーザー名 / アクセス元IPレンジ / 認証タイプ / 受信者属性を条件に
  • プロトコル / アプリケーション / サービス / リソースを使用できるか

アクセス制御が出来るようです。IntuneのExhange Online限定版といったところでしょうか。11月初めから展開を開始し、12月終わりには展開を終了する予定だそうです。

いやーマジか。OneDrive for BusinessでIPレベルのアクセス制御が出来るので、Exchange Onlineでも問題なく動くんだろうな～。

機能が便利になるのはいいですが、調子に乗って社内IPからしかアクセス出来ないように制限すると実は3rdパーティー製メールシステムからアクセスありました、とかなりそうなので、実装は慎重にしたい所。あとSIer的には"Exchange Onlineでのアクセス制御は構築対象外です"って入れとかないと大変そうです。

その他、SharePoint 新GUI関係の投稿が多数

いろいろありますが、SPOはただいま大工事中なので出来上がったサイトを見たほうが早いかもしれません。

MC117085 Changes to the Token Lifetime Default in Azure Active Directory

リフレッシュトークンを使用していない際の失効期間が14日から90日に伸びるそうです。

Changes to the Token Lifetime Defaults in Azure AD - Enterprise Mobility + Security

※ 既定の14日から変更している組織は対象外だそうです。

自分用に整理すると、Azure ADの代表的なトークンは2種類あり…

  • アクセストークン(Access Token)
    • アクセス先のシステムに渡すためのクレデンシャル。既定の有効期間は10分。ユーザー、クライアント、リソースの組み合わせ毎に発行される
  • 更新トークン(あるいはリフレッシュトークンと呼ばれる)(Refresh Token)
    • 上記アクセストークンとセットで発行され、PCにキャッシュされるクレデンシャル。更新トークンの有効期間中は更新トークンよりアクセストークンを生み出せるため、認証基盤に対しての再認証は不要である。

今までリフレッシュトークンの有効期間が14日だったので、長期休暇で14日間Office 365にアクセスしないと、15日目に再認証が求められていて、これがユーザー利便性を妨げていた、よって90日にした…との事。

ここからは余談で、私が良く分かってないのですが「Office 365への認証っていつ頃切れるの?(再認証されるの?)」って聞かれて、「14日間間を空けずに使い続ければ、最大90日間使えるよ」って説明しています。

参考：Office 365 のセッション タイムアウト - Office 365

これ、14日間というのが"Refresh Token Max Inactive Time"のプロパティであり、90日間というのが"Refresh Token Max Inactive Time (Confidential クライアントに発行)"なんですね。

Azure Active Directory における構成可能なトークンの有効期間 | Microsoft Docs

けど一方、上記ドキュメントの中に"更新トークンを使用して、現在のアクセス トークンの有効期限が切れたときに、新しいアクセス トークンと更新トークンのペアを取得します。"と書いてあます。これが正しいなら、アクセストークンは10分くらいで切れるため、キャッシュされたリフレッシュトークンを元に新しいアクセストークンを作成して認証に行くのですが、このタイミングで新しいリフレッシュトークンをゲットし、リフレッシュトークンの有効期限が更新されるんじゃないかな…と思ってたのです。

まぁこの"新しいリフレッシュトークン"によって更新されるのは、リフレッシュトークンの最終使用日時であり、これとは別にリフレッシュトークンの新規作成日時、みたいなデータを持っており、90日縛りは新規作成日時を元に確認されてるのかな…と無理やり納得してみます。

ここらへんの話、認証トークンの期限だけではなくアプリの作りにもよると思うので(OneDrive同期ツールなんて、一度設定したら90日経ってもパスワード変わっても再認証不要ですよね?)理解しづらい所だな、と思います。

第20回 Office 365 勉強会：感想

行ってきました。三連休のど真ん中で大丈夫?という話でしたが、私は前後仕事だったので大丈夫です。

セッションその1.NPOにOffice365Nonprofit版導入してみました

団体概要 | NPO法人 日本ジオパークネットワークさん?に導入したとの話です。以前、シャルマン火打に行ったときにNPO法人さんが糸魚川らへんに絡んでる、ってポスターを見かけましたが、その法人さんなんですね。

Office 365をNPOで採用した理由

  • 原則無料。
    • E1 0円
    • E3 410円
  • サービス継続性
    • サービス終了する可能性のあるサービスは採用できない
  • 知っている人が多いツールだから

です。GoogleもNonprofit版あるようなので、O365に価格優位性があるかはびみょーだと思いますが、サービス継続性という点では信頼性あると思います。知っている人が多い、というのは、転職の多い米国の会社は新入社員の教育コストを減らすためにWindows + Officeを導入するって話と似てるかなと思います。そこまでO365触った事がある管理者が増えればいいですけど…。

ポイント1. NPOライセンスの入手に手間取る

NPOであることを証明したり、直近の活動をまとめてTechSoup Japanに申請したりいろいろで、リードタイムが最大50日くらいかかるそう。よって試用版ライセンスで構築をはじめ、ライセンスが有効になった時点で付け替えを行ったそうです。ただ、Office365の試用版ライセンスはゴネれば90日まで伸ばせるので、リードタイムを考慮に入れておくだけで問題なさそうです。一般の企業でもライセンス購入の時期を遅らせたいがゆえに、あえて試用版をギリギリまで有効にすることはあると思います。

ポイント2. 片手間でやるのは大変だった

NPO法人は中小企業のようなもので、専任のIT管理者いない。また、以下の理由で複雑なシステム構成となってしまったので、片手間でやるのは大変だった、とのこと。総務兼IT担当のような方がOffice 365をとりあえず導入したってのはたまに聞くので(担当のPCスキルによっては)出来ない事はないと思うけど、以下のシステム構成では片手間では難しいよな…と思いました。

システムその1.連番メーリングリスト

連番メーリングリストとは何かというと

  • とあるメーリングリストアドレス(list01@ml.test.com)に送る
  • メールの件名が[list01:000001]件名となる
  • その後、同じメーリングリストアドレスに送ると、000001の部分がカウントアップする

システムであり、旧来的な日本企業で愛されているシステムである。Exchange Onlineにはこの機能がないので、別途メーリングリストサーバーを立てて、Exchange Onlineとあわせてメールフローを構築する必要がある。

これ、一応構築は出来て、僕自身、IIJのSecureMXを使うパターンとAzure上にmailman立ててIaaSで組むパターンの両方を検証(後者はどっかの案件で採用されてた)したのですが、いかんせんメールフローが複雑でSI費結構頂いた気がします。数百万だったかな…。別のメールドメインだったかな…。同一メールドメインけどいけた気がするけども。

話変わりますけど、せっかくExchange Onlineに移行するのに旧来の業務変えられないがために余計なコストかかるのはなんだかなぁと思うし、そこは業務変えろよ…と思いましたが、そのおかげで我々のお仕事があるわけです。

システムその2.SharePointの権限の話

支社毎に権限を分けたサイトを作成して、お互いが見れないような構成としたい。この時にSPOの権限設定を正しく構成するのに苦労した。具体的には、SharePointを2サイト目、3サイト目と作成していくと、気づかずに権限が付与され、2サイト目の人が3サイト目のサイトを見れるようになってしまう…。Office 365 高専高校情報漏洩事件もこのパターンで情報漏えいしちゃったんじゃないかとの話。

SharePoint権限はやり方を知ってるか知らないかだけの話だと思うけど(※私は知らない)、そういった要件に対応できる会社、エンジニアを探すのは大事なのかな、と思います。

セッションその2. Exchange Onlineの設計要素を抑える

このセッションは納得でした。Exchangeエンジニアなので…。やっぱり設計大変なところはみんな同じだな、と思いました。

LT

おかし

パステルのプリンです！

トイレ行って戻ってたらなくなってました。かなしいです。

LT1：PowerQueryって何なの?

Power QueryでJSONを簡単にパース出来る！しゅごい！

LT2：動画 + アンケートの話

SharePointサイトに動画を張り付けて、Microsoft Formsを下に配置すればいいよ、という話。

LT3：仙台IT文化祭の話

子供でもIT使っていて面白い気づきがあった、という話。

LT4：Office 365で実現する自己満足システム

ExOL → Functions → ぐるなびAPI → Teams

あーこれ、ほぼノンコーディングで出来るんだ…。実は自分で

  • ExOLの予定表の住所を検知して
  • 自社の住所と行先の住所をgoogle transitに投げて所要時間を算出
  • 前後に移動時間分の予定をオブジェクトを入れる

ってのをシステムでコーディングしたことがあるんですけど、これもFlowで出来そうだな…。

LT5：スタートアップこそOffice365で業務効率化

(経営者として)従業員の興味がDelveで分かるので、間違った方向に興味があるのなら軌道修正が出来るってのが面白かったです。あと、Flowがめちゃ使える！URL監視も出来るとは…。

セッションその3. MFCMapiを使ったExchangeのトラブルシューティング

オンプレ時代にMFCMapi.exe使いまくってたおじさん歓喜のセッションです。しかし最近はOutlookプロファイル再作成で直るトラブルが多いので触ってないですね…。

MFCMapi.exeで見れる全部の属性を把握し影響調査するのは難しいので、現実的にはお客さんの環境でよくある事象について情報を確認し、直す手順を確立し、それ以外のオペレーションはやらないってのがいいと思います。

SIer的な視点で言うと、手順ですぐ出来るからと言って、運用サービスメニュー1回30分とかではやりたくなくて、リスク費積みたいところです。リスク費が算出できなければ、例えばデータ消失・設定消失の可能性があるので、事前にユーザーメールボックスのデータと設定を抜き出すのに3時間かかるから、1回3時間30分です、みたいな立て付けをしないと。

Outlook for iOSの話とMSのサポートを担当されているベンダーさんのお話が面白かったです。確かに、Outlook for iOSから接続できないトラブルシュートはいろいろ大変かと思いますね…。

Microsoft 365 で両立するセキュリティと働き方改革

MSさんが今一押しのMS365の話です。お高いライセンスを買わないと使えないってのはあるものの、セキュリティインシデントが発生した企業さんではトップダウンで導入が決定されたりして急にSIerが呼ばれたりします。ATPは出始めに比べるとほんま良くなったと思います(動的添付ファイル配信とか)。構築コストが少なくSIerが介入する余地がないのがアレですし「いやぁ～ふるまい検知のおかげでイスラエルからのアタックに気づけたよ～」という話をお客様から聞けないので、自信を持って性能の良さを語れないところではあります。。。

※ 途中で気づいたけど、スピーカーの小町さんってde:codeでWindows Hello for Business ハイブリッドのお話しされた方だったのか。Pass-the-Hashの発音が同じだったから気づけました。あのセッションはテクサミの展示作るのにめっちゃ聞きました。

まとめ

今回は4セッション中3セッションが得意分野だったので新しい気づきは少なかったですが、自分の知識を確認するいい機会となりました。LTのFlow大活用術は参考にしたいと思いました。ビジネス面の話だと、E1以上のお客様ならライセンスは持っているので提案環境は整っているが、"メールシステム"や"グループウェア"といったカテゴリでくくれない部分なので、営業も売りづらい・お客さんも使い方のイメージがない。なので、エンジニア側があれこれできまっせ、って事例集を持参して、その中からお客さんのやりたい事引き出して、フローを組んでやるって、感じなのかな…。

あと、フローで出来ない部分はAzure Functionと組み合わせりゃ何でもできるぜしお金ももらえるぜ、って話だったけど、ここまですると、Flowベースの考え方というより、開発する機能の一部としてFlowを組み込む形になるので、Office 365エンジニアじゃなく開発エンジニアがO365のAPI使って何かやる時にFlow使って工数削減しない?とアプローチする感じかな。。。

Flowの話にそれてしまいましたが、主催者のみなさん、定期的な勉強会の開催ありがとうございます。また次回も参加させてください。

Office 365 (Exchange Online)の新しい予定表共有について

support.office.com

2017年9月くらいからひそかにOutlook for iOSで他人の予定が見れてざわざわしたのですが、MSのページを見つけたので読んでみます。

予定表共有の権限種別について

簡単に言うと、今までの"複雑な"予定表権限が、"シンプルな"ものに置き換わり、このシンプルな権限で共有をした場合、Outlook on the webで予定表の共有をした情報がOutlook for iOSなどに同期されるようです。

  • 現在PC版Outlookで選択できる予定表閲覧権限は"レガシーであり複雑"な共有方法である
    • 確かに、従来Outlookから選択できる予定表権限は"参照者"やら"寄稿者"やらパッと見意味が分からないものが多かった。
  • Outlook for iOSやOutlook on the webで選択できる予定表閲覧権限をシンプルな共有方法としている(記事中では"Simplified permissions"と呼ばれている)
    • Outlook on the webからsharing invitation送ろうとするとシンプルな権限しか表示されないけど、今後はこれがデフォルトとなるようです。

これ以降、前者を"旧権限"、後者を"新権限"と呼ぶ。

PC版Outlookでは2017年4QのUpdateで新権限による予定表共有が出来るようになり、新権限による予定表共有を行う事で、PC版Outlookで閲覧した他人の予定表をOutlook for iOS,Outlook on the Webで閲覧できるようになる…ようです。

なお、既に旧権限で予定表を共有しているユーザーを新権限で上書きする場合、以下の方法が必要となる

  • 予定表オーナーに再度予定表共有インビテーションを出してもらい、OKボタンをクリックする
  • (過去に予定表共有インビテーションをもらっている場合)そのメールのOKボタンをOutlook for iOSからクリックする。この時、PC版Outlookからクリックすると無効なので注意

シンプルに、削除→再度共有依頼がよいのではないかと。

予定表共有の権限種別について：疑問

新権限での共有はユーザー個人を対象にしか出来ないのか?

  • 旧権限による予定表共有は、"既定"の権限を"参照者"などにして、自分が許可せずとも他人が勝手に自分の予定を見れる仕組みであった。新権限による予定表共有はsharing invitationを飛ばさなければならず、いちいち自分が許可する必要があるし、他人の予定を見る時にも許可を得る必要がある。よってユーザー利便性が低下する
  • これを防ぐためには、powershellか何かで事前に新権限による共有権限を管理者側でセットすれば回避できるのか検討する必要がある。例えば、A,B,C,D,Eが同じ部署なら、AにはB,C,D,Eへの予定表閲覧権限、BにはA,C,D,Eの…といった具合
    • ただ、システム的に上記が可能だとしても運用はとても回らない
    • よって、やはり"既定"やセキュリティグループ単位で"新権限"の付与を管理者側でしたい
  • "旧権限"は必要以上に細かい権限設定が出来きるため混乱の元であり、大半の要件は新権限で満たせると思いますが、細かい権限設定を利用して運用している現場があれば検討をする必要がある。

新しい予定表同期ロジック(instant syncing)

権限種別もリセットされるらしいが、予定表同期ロジックも変更になる様子。現状、Outlook on the web,Outlook for iOSで使用でき、PC版Outlookは2018年夏にリリース予定。

※ 分かりやすいよう、これ以降は旧方式・新方式と呼びます。

詳しくは"Technical details of the shared calendar improvements"以降を読めばわかるが、旧方式に比べて新方式の方がよくなっているよ…と主張している。が、エンジニア的には挙動が変わるから要チェック、くらいの意識がよい。例えば、新方式の特徴として、共有相手のカレンダー情報をローカルに保有するため、データへのアクセスが早くなる、などいろいろあるが、ネットワーク負荷が増えないか?共有相手のカレンダーに添付ファイルがめちゃくちゃついてたらどうなるのか?など気になります。

共有カレンダーのリマインダーの挙動も変わる様子。理由として、旧方式では共有カレンダーに毎回アクセスしていたが、新方式だとローカルコピーを持つようになるためと書いています。すんません、共有カレンダーあんまり使ってないので感覚が分かりませんが、使っているところは大きな変更になるのかな?

一番気になる所、というかよくわからないはPC版Outlookの対応が2018年夏ということ。

"Summary of experiences across clients"に今後のリリース予定が書かれています。

つまり"PC版Outlookで共有した予定をOutlook for iOSでも閲覧できるようになる"というのは、このinstant syncingがリリースされてから?それとも、instant syncingはあくまで同期ロジックの話で、カレンダー共有については2017年4QのUpdateで使えるようになる?

とにかく今は2017年4QのPC版Outlookへの実装待ちであり、その時いろいろ確認するしかなさそう。

Monthly Office 365 Update (9月分)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。飽きたらやめます。

チェックソース

※ TechPlusライブラリはMSパートナーじゃないとアクセス出来ないので注意

Office 365 メッセージセンター

  • MC118065：更新された機能: # および SharePoint Online で OneDrive % のサポート
    • ファイル名に#や%が付与されたファイルをアップロードできないという致命的な欠陥があったが、サポート対象に。実態参照に置き換えてくれるのでしょうか?確か7月くらいから一部のテナントでは有効になっていた気がします。
  • MC118273：新機能: Yammer デスクトップ アプリ
    • 新しくなったよ！…と言っているが、現状もブラウザ版と同等の機能しか使えず。今の所、インストールする意味は薄いと思われる。
  • MC118596：新機能: マイクロソフトのチームにゲスト アクセス
    • 9月で一番話題だった機能。
  • MC118786：更新された機能: Office 365 アプリケーション ランチャー
    • 最近よく使っているアプリを優先的に強調表示するように変わる、という話。確かにアプリ数も多くなってきたからいいのかな?Flowとか下の方に行っちゃう可能性あるけど。
  • MC119974 更新された機能: 携帯電話上のカレンダーを共有
  • MC119976 更新された機能: マイクロソフト チームの監査ログ
    • Teamsの監査ログがアップデートされ、タブ作ったりコネクター作ったりするログも取れるようになる、と。お一人様チーム作って遊びのyoutubeタブで動画見ててもタブ作った時点でばれる、ということです。なおyoutubeタブ作ること自体は、Teamsの管理画面から制御できます。
  • MC120741 新機能: 利用状況レポート
    • Teamsに関してのユーザーアクティビティとアプリ使用状況がレポートになるという話。また電話会議などの回数も取れる。ExOLやSfBのグラフのイメージですかね。その他、データがAPIで取れるようになったり(前から?)管理者権限を付与しなくても、利用状況だけを見れる権限を付与する事が出来る。
  • MC119954 Known Issue: Email access in iOS 11
    • iOS 11で既定のメールアプリからExchange Onlineにつながらない問題。11.01で直ったっぽい。
  • MC121151 Updated feature: Message center rich formatting
    • メッセージセンター内のメッセージにyoutubeとか埋め込んで分かりやすくするよ！という話。
  • MC121194 New feature: Message Center major updates

以前から予告されていた、週間ダイジェストをメールで送ったりなどの機能が追加されるらしい。

TeckPlus編

今回は当たりの資料が多かったです。

Microsoft_Teams全体説明資料1チーム向け機能と制御・管理編_201707.pptx

  • P10-17,P64-P66 チームの仕様と制御方法
  • P32 メンション
    • 90分確認しなければメール通知
  • P34 チャネルに対してメールアドレスで投稿可能
    • 知らなかった。これでチャネルへのpostが容易に
  • P42 Teamsファイル共有の仕様
    • 方法によってteamsのsharepointか個人のonedriveかのどちらに保存されるか分かれる
  • P61 秘書bot
    • 使い方が分からなかったので参考になった。