Monthly Office 365 Update (12月分)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。年の瀬12月分。今月は少ないかも。

チェックソース

Office 365 メッセージセンター

MC126127 Updated feature: New sharing settings in Microsoft Forms

Fromsで作成したアンケートをは以下の4種類の方法で外部と共有できる

  • 共有して共同作業する
  • テンプレートとして共有
  • 回答の送信と収集
  • 結果を共有

このうち「回答の送信と収集」「結果を共有」は現状外部へのリンク送信を禁止するようコントロールする事が出来るが、今後のリリース(12月末予定)で残り2つのリンクの制御も可能となる。

MC126199 We are moving to TLS 1.2 for encryption

2018年3月1日にOffice 365がTLS 1.2に移行し、1.1、1.0が使えなくなります。世の中的に、2018年6月30日でTLS 1.0を使うなよ、というアナウンスは出ていますし、スターバックスのサイトなどは既にTSL1.0/1.1が無効化されています。

ので、Office 365が特別な対応をしているわけではないのですが、得てして企業システムはレガシーなシステムが動いている事が多いので注意が必要です。

気になるのは

  • プロキシサーバー
  • MTA
  • ADFS/AADCなど

でしょうか。MSは”TLS1.0/1.1での接続はほぼない事を把握している”と言っていますが、それなら管理者がポータルから状況を確認できるような仕組みを作って安心させてほしい…。O365セキュリティスコアとかの前に…。

Windows Hello for Business ハイブリッド キー信頼構成で実現する、Azure AD Join端末からオンプレADへのシングルサインオン

このエントリではTechSummit 2017で実施した展示の技術解説を行おうと思います。といっても展示するシステム自体、テクサミ1週間前くらいから急ピッチで構築して「とりあえず動いた…。もう触らんとこ…」であり仕組みまで深堀出来てません。そんな浅い理解ですが、ナレッジはナレッジなので展開し共有します。

目次

  • Windows Helloとは?
  • Windows Hello for Businessとは?
  • (余談)PIN・パスワード・生体認証の安全度考察
  • Windows Hello for Business ハイブリッド構成のパターン
  • Windows Hello for Business ハイブリッド キー信頼構成の構築手順
  • なぜWindows Hello for Business ハイブリッドでAzure AD Join端末からオンプレADにSSOできるのか

Windows Helloとは?

パスワードの代わりに、PIN/生体認証でWindows端末にログインする仕組みです。

f:id:teraco:20171229143302j:plain
f:id:teraco:20171229143304j:plain

Windows Hello for Businessとは?

ざっくりいうと、ポリシーを利用してPIN/生体認証でのログインを”強制する事が出来る”機能です。”強制する事が出来る”というのがポイント。

“ユーザーの希望に応じてPIN/生体認証でWindowsログインできるようにする”という要件を満たすだけならWindows Helloでよいのですが、Windows Helloの欠点はユーザー自身が設定しないとPIN/生体認証でログインできない事です。

情シス視点で

  • ポリシーを強化し、パスワードを複雑にしたい
  • それだけだとパスワードをメモして付箋で貼り付けるユーザーが続出する
  • なので、PIN/生体認証を利用してパスワードを利用せずWindowsログインできるようにしたい

という狙いの場合、単純にWindows Hello環境を整えてユーザーに設定手順書を渡しても「あ~、情シスから設定してくれってメールきたんだけど、よく分からないし指紋登録とかヤだから、今まで通りパスワードでログインしてるよ」となるのは容易に想像できます。

Windows Hello for Businessなら、グループポリシーでパスワードの複雑性を定義するのと同じ感覚で、ドメイン参加後にPIN/生体認証の登録画面に飛ばす事が出来ます。

具体的には以下の動画をご覧ください。

Windows Hello for Business: What’s New in 2017 – BRK2076 – YouTube

実はこのPIN/生体認証登録はスキップする事が出来ますが、登録しない場合、PCにログインするたびにこの画面が表示されるので、半強制的にPIN/生体情報を登録させることができます。

Windows Hello for Businsssのセキュリティ

もう一つのメリットとして、Windows Hello for Businessではクライアント⇔サーバー間の通信がPKI(公開鍵基盤)のロジックに変わります。

説明しますと、普通のWindows Helloでは、PCログイン時にPIN/生体認証を使用してログインするものの、その後は、PC内に保存されているパスワードハッシュをADに向かって投げつけるので、ログオンの瞬間以外は普通のパスワードログインと変わりません。

f:id:teraco:20171229143304j:plain

一方、Windows Hello for BusinessはクライアントPC ⇔ ドメインコントローラー(あるいはAzureAD)間の認証が、公開鍵基盤認証の仕組みで認証されるようになります。クライアントPC視点でドメインコントローラー(あるいはAzureAD)が認証局として動作します(するようです)。よって途中のパケットをキャプチャされても、もちろんパスワードは分かりませんし、公開鍵基盤認証の仕組み上、成りすましログインも出来ません。

f:id:teraco:20171229152247j:plain

すごい!!!!!!!

…しかし、この説明を聞いて「うお~すげ~!Windows Hello for Business導入するしかね~!」と思った人はどれくらいいるでしょうか?

MS側は”Windows Hello for Businessの一番のメリットはセキュリティだ!”とか言ってるのですが「パスワードハッシュが社内ネットワークを流れてるの、前々から問題だと思ってたんだよね~」という意識高い情シス担当者は少ないので、実際にこの点をメリットとして宣伝するのは、かえって混乱を招くんじゃないかな…と思います。現場の情シスさん、そんな高度な問題より、付箋にパスワードを書くようなユーザーに悩んでると思うんですよね。しかも、Windows Hello for Businessを構成後も、PCの内部にNTLMハッシュを持つので、Pass-the-Hash攻撃などは普通にやられるようです。

f:id:teraco:20171229144336j:plain

ひとまず、このエントリに限っては、パスワードハッシュがネットワークを流れずセキュア、というのは忘れてもらってよいかなと思います。一方Windows Hello for Businessは公開鍵基盤認証であるというのは、覚えておいてください。

Windows Hello for Businsss:よくありそうな質問

  • Q:Windows Hello for Businessを展開すればユーザーにパスワードを教えなくてもいい?
    • A:×誤りです。初回セットアップ時にADのユーザー名/パスワードが必要です。
  • Q:Windows Hello for Businessを展開すればPass the Hash攻撃されても大丈夫?
    • A:×誤りです。端末にパスワード情報が保存されるので、盗まれます。
  • Q:Windows Hello for Businessを展開すればネットワークにパスワードハッシュが流れない?
    • A:×誤りです。サーバーにNTLM認証を求められた場合、キャッシュされたパスワードハッシュを提供します。
  • Q:PINでのログインを禁止して、生体情報だけを許可する事は出来ないの?
    • A:×出来ないようです。システム的にはPINも生体情報も同じくらいセキュアと扱われています。

Windows Hello for Business ハイブリッド構成のパターン

さて、Windows Hello for Business ハイブリッドを構成するわけですが、4つの構成方法が提示されています。

Windows Hello for Business (Windows 10) | Microsoft Docs

  • Key trust Group Policy managed
  • Certificate trust Mixed managed
  • Key trust Modern managed
  • Certificate trust Modern managed

判断ポイントは2ポイントで

  • キー信頼モデルか、証明書信頼モデルか
  • グループポリシーでの管理か、Intuneポリシーでの管理か

です。今回はPOCだったので管理手法は別として、キー信頼モデルか、証明書信頼モデルかを検討しました。結論としては、両者に性能的な違いはなく導入する環境や使用予定のコンポーネントによって構成を決定すればよいとドキュメントに書いてあったので、比較的構築が楽なキー信頼モデルを採用しました。

Windows Hello for Business ハイブリッド キー信頼構成の構築手順

以下のマニュアルを見ながら構築しました。11/5時点では全て英語となります。証明書信頼モデルのマニュアルは日本語なのに…。

Hybrid Key Trust Deployment (Windows Hello for Business) | Microsoft Docs

簡単に手順を書きますと

  1. Hybrid Azure AD Join環境の構築
  2. 証明書テンプレートの入れ替え、KeyAdminの同期
  3. 各種ポリシーの設定

の3段階に分かれるかな、と思います。時間がかかるのはHybrid Azure AD Join環境の構築かと思いますが、こちらは割と世の中にナレッジがあるのでいけるんじゃないでしょうか。証明書テンプレートの入れ替え移行は手順通りに進めました。あまりやったことがない手順なのでビビりながら。

なぜWindows Hello for Business ハイブリッドでAzure AD Join端末からオンプレADにSSOできるのか

システム構成図はこんな感じです。

f:id:teraco:20171229153606j:plain

Windows Hello for Business ハイブリッドの手順の一環で、Hybrid Azure AD Join デバイス構成を構築します。

How to configure hybrid Azure Active Directory joined devices | Microsoft Docs

この構成では、Azure AD JoinしたWindowsPCの情報がオンプレミスのActive Directoryにコピーされます。具体的には以下のPC02です。

f:id:teraco:20171229155107j:plain

さて、Windows Hello for Businessは公開鍵証明書基盤の仕組みを利用して認証を行います。PC端末とAzure ADがクライアントと認証局の関係となり公開鍵証明書基盤方式で鍵をやり取り。最終的にクライアントPCが認証局から発行された認証トークン(?)をPC内部に持つと思われます。

仮のこのPCがオンプレミスのADに参加していた場合、Azure AD Joinした場合と同じデバイス情報がオンプレミスのADに作成されると思われます(これ、確認したい)。そしてオンプレミスADと公開鍵証明書基盤方式で鍵をやり取りし、最終的にクライアントPCが認証局から発行された認証トークンは、Azure AD Joinした時に発行されるものと同一となります。

f:id:teraco:20171229155443j:plain

以上より、Azure ADから発行された認証トークンを持ってオンプレADにログインしようとした場合、その認証トークンはオンプレADでも使えるものなので、オンプレADにシングルサインオンが可能となります。オンプレミスのActive DirectoryクラウドのAzure ADが同一の認証局となることで、クライアントPCがAzureADからもらった認証トークンはオンプレADでも使用できるものとなります。

…という理解です。恥ずかしながら上記動作はあくまで推測です。ネットワークキャプチャして通信暗号化解除して追えばわかると思いますが、そこまでの元気はありませんでした。。。

ただ、公式ドキュメントにAzure AD Joinしたデバイス情報がAADCでオンプレADにコピーされるまで、オンプレADへのSSOは出来ない、と書いてあるので、Hybrid Azure AD Joined構成でコピーされるオブジェクト情報が鍵を握っているのは間違いないと思います。実際、AADCでデバイス情報同期される前にオンプレADにアクセスした場合、シングルサインオンできなかったので。

ここらへん、ほんま自信なくてイベログにもそれっぽいログが出てなかったので、状況証拠からの推測でしかないんですよね…。ドヤったブログタイトルなのにすいません。

そして…課題

課題1. 初回ログイン後、一度サインオンすると、オンプレリソースへのシングルサインオンが出来ない。

なので使い物になりませんwww PCへの初回ログインや、別ユーザーで一度ログイン後、再ログインするとシングルサインオン出来るのですが…。これは僕の構成が間違っていたのか、そもそもバグなのか分かりません。初回ログイン時にシングルサインオン出来ているので、普通に考えると2回目以降もいけそうな気がするんですけどね。

おそらく、初回ログオン時はAzure ADからうまくトークン(?)を取れて、そこでオンプレリソースにSSO出来るのでしょうが、2回目以降のログインでは下手にPCのキャッシュを使ってWindowsにはログインできるが、PKI認証用の情報は消えてしまっている & 取得していないのでSSO出来ないのか、と思います。

課題2. オンプレADへのWindows Hello for Businessポリシーテンプレートが見つからない

本来的にはオンプレADにGPO適用し、オンプレADにデバイス登録されたPCにWindows Hello for businessを強制するようにポリシーを適用したかったのですが、テクサミ時点では管理ポリシーが見つからず、Azure AD Joinした端末にしかWindows Hello for businessを適用できませんでした。ここらへん、最近のyoutubeでは”オンプレもポリシー適用できるぜ!”って言ってるので、今は大丈夫かもしれません。

参考にした情報

docs.microsoft.com
www.youtube.com
channel9.msdn.com

www.slideshare.net

最後に

Windows Hello for Business ハイブリッドはまだ情報も少なく、本番導入時にどこでハマるか分からないので、新しい情報は積極的にキャッチしてアップデートしていけたらと思います。

Monthly Office 365 Update (11月分)

Office 365のアップデートを定期的にチェックして気になったものをピックアップするシリーズ。めっちゃさぼってました。ひとまず11月分。

チェックソース

Office 365 メッセージセンター

MC124470 New feature: Microsoft Flow in OneDrive for Business

OneDrive for Businessのメニューの1つにFlowが表示されたよ、って話。前々からFlowでOneDrive for Businessは使えましたがFlowの画面から設定する必要があった。これからはOneDrive for Businessから設定できるが、情シス視点ではユーザーからの問い合わせに答えなければならず、大変そうですね。

MC124493 New Feature: Idle Session Timeout Preview Available in SharePoint Online and OneDrive for Business

10月の更新で言及された”MC117085 Changes to the Token Lifetime Default in Azure Active Directory“(Monthly Office 365 Update (10月分))とは別に、SPO,OD4Bでセッションタイムアウトが管理者側で決められるらしい。しかしながらこれについて説明された文章(Introducing Idle Session Timeout in SharePoint and OneDrive (Preview) – Microsoft Tech Community)を見ると、ユーザーがセッション保持を継続するオプションを選択すれば二度目は聞かれない、という事が書いてあるようにみえ、セキュリティ強化には繋がらないのでは、と思いました。

※ 本当にセキュリティ強化したいなら、一定時間毎にパスワードを入れ直す、などが必要。

MC124939 New feature: Message Center major updates

メッセージセンターで重要なお知らせのクローズアップやメールでの通知が実装できるようになったよ、という話。これはだいぶ前から展開が開始され、100%のテナントに展開が終了したとの事。次は前々から予告されているVIPユーザー監視機能のリリースをおなしゃす…。

MC125028 New feature: Compliance Manager public preview

コンプライアンス マネージャー管理画面のプレビューです。これ系のポータルではセキュリティ/コンプライアンスセンターがありますが、別物です。テクサミ感想のGDPRセッションに書いたけど、GDPR対応のためにMSではソフトウェアベンダーとして出来る限りの対応をする、と表明されており、このコンプライアンス マネージャーを使えば、自組織のOffice 365がどれだけGDPRに順守しているか(EUから刺されないように対応しているか)分かります、との事。

指標としては、既存のセキュリティ/コンプライアンスセンターのように各規格(GDPRはもちろん、その他国際規格)に対する”スコア”と”スコアを上げるための対策”が表示されるものとなってます。

ただ…。GDPRに関してはどういう条件でEUに刺されるかがまだ未定。なぜならGDPR運用開始が2018年5月だから。そこでMSは「E5ライセンスでSPOなどのデータにラベリングしてDLPで監査すれば情報管理してるって言い張れます!」ってアピールしてるんだけど…。これでEUに刺されないかどうかは誰も知らない。

MC125181 Updated Feature: New sharing tab in OneDrive for Business Admin center

Onedrive for Business管理センターの共有設定が分かりやすくなったよ、という話。確かに分かりやすくなってました。できる事は前と変わってません。

MC125218 New Feature: Focused Inbox

優先受信トレイがほとんどのテナントで有効になったよ、という話。無効にする方法はこちら。

組織内のすべてのユーザー用に優先受信トレイを構成する – Office 365

MC125489 New features: OneDrive for Business for iOS

OneDrive for BusinessのiOSアプリが新しくなるよ、という話。D&Dが可能になる、iOSのファイルアプリがサポートされる、130種類ほどのファイルがOneDriveアプリ内でプレビュー可能になる、など。IntuneのMAMについても動作確認済みなので安心。

追加費用なしでアクセス制御を実現できる、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はpowershellREST 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さんです。お楽しみに!