皆さんこんにちは。国井です。
先週はもともと海外出張に出る予定だったのですが、コロナウイルスの影響でキャンセルになってしまいました。そのため、2020年4月にスタート予定の「Microsoft 365 を利用したインシデント対応」トレーニングコースの制作を地道に行っておりました。ただ、書くことがあまりにもたくさんあり過ぎて、テキストから除外することになったトピックがあるのでシェアしたいと思います。

ちょっと広い視点から

Microsoft 365を利用するメリットには色々なものがあると思いますが、そのうちのひとつに「セキュリティ」があると思います。セキュリティ対策には防御、検知、対応のプロセスが必要と最近はよく聞きますが、

検知ってどうやってやるの？
対応ってどうやってやるの？

という話はお客さんと話をしていると、割とよく聞く話だったりします。
フルマネージドなサービスに入って専門家に面倒を見てもらっている会社さんならまだしも、Microsoft 365を買ったんだから自分たちでやりたい (もしくは「やれ！」と言われている) 会社さんもあるのではないかと思います。
Microsoft 365には、Office 365 ATPやMicrosoft Defender ATPなどのサービスを通じて不正アクセスの検知や対応ができる仕組みを用意していて、自動インシデント対応や自動調査の仕組みがあるから、本当に対応が必要なものに注力できると、マイクロソフトは言います。

しかし、ボットに感染した、ランサムウェアに感染した、などの自動調査機能で対応できる、ありきたりの攻撃であったとしても、これからインシデント対応の業務に従事する人からしてみれば、「ありきたりではない」わけです (誰でも初めてってありますからね)。
そのため、どういう攻撃があれば、Microsoft 365でどういうアラートを出してくれて、どのようなインシデント対応が必要なのか？そして何を自動化してくれるのか？を体験しておかなければ「ありきたり」な攻撃であったとしても、対応を誤る可能性がありますし、対応方法の策定段階から適切な設計ができない可能性があるわけです。

そこで、Microsoft 365 を利用したインシデント対応というコースを作ったわけですが、そこでベーシックな攻撃とその対応を見てみようと思います。(前置き長い！)

ランサムウェア？に感染してみた

マイクロソフトではMicrosoft 365を利用してインシデント対応を行う際に利用可能なシミュレーションとして、いくつかのサンプルを用意していて、その中のひとつにランサムウェアがあります。

http://aka.ms/ioavtest

ファイルをダウンロードして実行すると、わかりやすいメッセージ画面が表示されます。

実際にはファイルが暗号化されることはなく、ランサムウェアというよりはジョークウェアだったりします。なので安全にどこでも検証できるのですが、実際にはMDATPなど使わなくてもWindows Defenderウイルス対策で検出できます。
ですが、そこは敢えてWindows Defenderウイルス対策で検出できないように設定しておいて、あらかじめMDATPでオンボーディングしておいたデバイスから無理やり実行します。

MDATPでインシデント対応

中身はどうなっているかMDATPで見てみます。
上記のURLからダウンロードしたファイルはvalidatecloud.exeという名前で、MDATPの[Machine list]から特定のデバイスを選択し、[Timeline]を選択すると、以下のようにvalidatecloud.exeにアクセスしている様子が確認できます。
(※ちなみに画像はインシデント対応した後のものなので、Remediatedとなってます)

特定のタイムラインをクリックすると、その詳細が確認できます。ここで気が付いた方もいると思いますが、今回はブラウザーからダウンロードしているので、パスがMicrosoftEdge配下になっています。言い方を換えると、このマルウェアはブラウザー経由で流入したものだとわかります。

続いて[Alert]メニューを確認します。
MDATPではマイクロソフトが保有する「インサイト」と呼ばれる情報などと照らし合わせて、不正アクセスと思われる事象があれば、アラートを発生させます。
今回はvalidatecloud.exeがマルウェアだということは既に知っていることなので、Timelineから見ましたが、現実の世界ではアラートから確認していくのが一般的なアプローチになります。

特定のアラートを開くと、アラートへの対応状況を記録しておけます。

続いて[Incident]メニューを確認します。MDATPを使い始めると、インシデントとアラートは何が違うの？ってところが最初のつまづきポイントになるのですが、
国井の勝手な解釈では

アラートは不正アクセスと思われる事象
インシデントは発生したアラートに対して行うべき作業をまとめたもの

という違いがあります。
例えば、マルウェアに感染してボット経由で遠隔操作されている場合であれば、
マルウェア感染と、ボット経由の遠隔操作、の2つがアラート、
インシデントは一連のアラートをまとめたもの
ということになります。

ですので、インシデント対応をするときは、アラートで事象を確認し、
個々の攻撃の関連性などの確認・管理はインシデントメニューから、という感じです。

インシデントメニューから特定のインシデントを選択すると、下記の画面が出てきます。
画面の中ではインシデントに関わったデバイスやファイル群を確認できます。

さらにGraphタブをクリックすれば、上記の内容を可視化したグラフが表示されます。
以上のものを利用することで、今回のインシデントの特徴であったり、影響範囲であったりがわかるわけです。

最後に[Advanced Hunting]メニューを使ってみましょう。
Advanced HuntingはMDATPが収集したログに対するクエリ機能で、以前にも使い方を紹介させていただきました。

http://azuread.net/2019/06/18/microsoft-defender-atp/

これを使って、validatecloud.exeの利用状況を確認してみます。
ファイルの実行(プロセス)イベントはDeviceProcessEventを利用して次のように書きます。

DeviceProcessEvents
| where FileName =~ "validatecloud.exe"

すると、ログがひとつだけ表示されました。InitiatingProcessFolderPath項目を見ると、browser_broker.exeによってvalidatecloud.exeが扱われていることがわかります。前にも言いましたが、ブラウザーからvalidatecloud.exeをダウンロードし、実行することで感染したことがわかりますね。

ここまで大雑把な説明になってしまいましたが、MDATPでは以上のようなメニューを利用して様々な攻撃を検知し、そして調査する、修復することができます。

じゃあ、これがアプリケーションの脆弱性を悪用した攻撃だったらどうなのか？標的型攻撃だったらどうなのか？またはMDATPがアラートすらあげないような特殊なケースだったらどうなのか？などを一度検証しておくと、安心してMDATPを御社のインシデント対応プロセスの中に組み込めるようになると思うのです。

それはご自身の会社の中で行っていただいてもいいですが、トレーニングコースでも一通り見ていただけるものを用意しましたので、ご興味があれば参加してみていただければと思います。

皆さんこんにちは。国井です。
前回に続き、Microsoft Defender ATPの話、それも備忘録です。
Windowsデバイスを舞台にした不正アクセスにPowerShellが使われることが最近多いと思います。そのため、PowerShellを実行した履歴を追跡したいなんて要望もあるかと思います。Microsoft Defender ATPの場合、コマンドレットを実行すればタイムラインに次のような履歴が残ります。

PowerShell ISEの場合はこちら。

ただMDATPのタイムラインには、具体的に何を実行したかは記録されません。
そのため、タイムラインで「なんで、このタイミングでPowerShellなの？」という事象が発生したら、該当のコンピューター上でGet-Historyコマンドレットを実行すれば具体的に実行されたコマンドレットまでわかります。そこで、Invoke-WebRequest.. なんて履歴があったら、自分の頭の中でアラートがあがるわけです。

一方、Get-Historyコマンドレットで追跡できるコマンドレットの実行履歴は直近のバージョンのPowerShellを実行した場合であり、前のバージョンのPowerShellから実行されると履歴は残らなくなります。これを逆手にとって、わざと古いバージョンのPowerShellを呼び出して実行するような輩がいるんですよね。

powershell.exe –v 3 Get-Childitem

ですが、もしcmd.exeなどからPowerShellコマンドレットが呼び出されていれば、MDATPのタイムラインから特定のログを参照すると、Command line欄に実行したコマンドレットが確認できます。

また、個々のコンピューターで確認するのであれば、ダウングレードしたバージョンでコマンドレットを実行すると、イベントビューアのWindows PowerShellログにイベントID 400が記録され、その中で実行したコマンドレットが確認できます。

余談ですが、Windows PowerShellのイベントログを消してしまうという方法で
コマンドレットの実行結果を消すこともできますが、システムログのイベントID 104で
消したという履歴は残るので、消した覚えがないのに104が出ていたら、調査しなきゃ！という次のアクションにつなげることもできるようです。

皆さんこんにちは。国井です。

Azure ADで管理ロールを使った作業を行う際、繰り返しの操作があればPowerShellを使って操作したりするようなことってあると思います。そのとき、いちいち資格情報を入力するのが面倒だからという理由で次のようなことをするような方もいらっしゃるのではないかと思います。

$cred=Get-Credential
$cred.password | ConvertFrom-SecureString | Set-Content "password.dat"

$password = Get-Content c:\password.dat | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PsCredential "admin@xxxx.onmicrosoft.com", $password
Connect-AzureAD -Credential $credential

便利な機能ではありますが、万が一password.datファイルが盗まれたら？と考えるとぞっとしますし、昨今の標的型攻撃の被害に遭えば、こうした事態は簡単に起こりえることだと思います。

そのため、(どこだったか忘れたけど)MSさんでは管理作業を使うときは次のようなことを推奨しています。

1．マネージドIDを使うこと
2．サービスプリンシパルを使うこと
3．最小権限のアカウントで操作すること

1.と2.はいずれもユーザー名とパスワードを入力しないで管理作業を行う方法です。
ユーザー名とパスワードを入力しないで、どうして安全なの？と思われた方はこの先をお読みください。

マネージドID

マネージドIDとは超絶ざっくり言うとサービスアカウントのことです。
特定のサービスを利用するために用意されたIDでMSサイトによると以下のAzureサービスで利用できるようになっています。

・Azure Virtual Machines
・Azure Virtual Machine Scale Sets
・Azure App Service
・Azure Blueprint
・Azure Functions
・Azure Logic Apps
・Azure Data Factory V2
・Azure API Management
・Azure Container Instances
・Azure Container Registry
・Azure Service Fabric

これらのサービスを管理するときにマネージドIDを利用すると
Azureの管理アカウントのユーザー名とパスワードを使わないでも
管理ができるようになります。
設定方法は、、って書こうと思ったら、既に紹介してくださっているブログがあったので、ご紹介しておきます。

簡単に言うと、特定のサービスだけで利用可能なアクセストークンを発行し、
そのトークンがあれば、管理が可能という仕組みです。
Azure VMの場合であれば、VM作成時にマネージドIDを利用するように設定しておけば、PowerShellからVMを管理するときにアクセストークンを指定して接続することができるようになります。

サービスプリンシパルを使う

サービスプリンシパルとはAzure ADのようなID基盤に登録されたサービスのことで、サービスプリンシパルとして登録されたサービスからのみAzure ADによる認証・認可を利用できるようにするという機能です(ちょっと古いですけど、サービスプリンシパルについて書いた説明があるので、こちらもよろしければご覧ください)。サービスプリンシパルを使うと、ユーザー名とパスワードの代わりにアプリケーションを識別する情報を利用したアクセスを実現します。サービスプリンシパルの作り方は次の通りです。

1.
Azure AD管理センターから、[アプリの登録]を新規作成します。これによりサービスプリンシパルが作成されます。
(厳密にいえば、[アプリの登録]を行うことにより作られるエンタープライズアプリケーションがサービスプリンシパルになります)。

2.
[アプリの登録]に作成したサービスプリンシパルから発行されるクライアントIDを控えておきます。これが認証におけるユーザー名みたいなものです。

3.
[アプリの登録]でクライアントシークレットまたは証明書を作成しておきます。これが認証におけるパスワードみたいなものです。

4.
[アプリの登録]でAPIアクセス許可を割り当てます。

ここまでができたら、Azure AD(もしくはAzure)の管理を行うクライアントアプリケーション(例えばPowerShellなど)にクライアントIDとクライアントシークレット (または証明書) を登録しておくことで、実行すると管理に必要なアクセストークンを取得できるようになり、管理が始められます。ここまでの話をまとめると、こんな感じのアクセスになります。

これを実際に実装しているのが、以前の投稿でPowerShellでAzure ADのログを収集する投稿を書いたこちらになります。

このやり方を応用すれば、様々な管理ができるようになります。例えば、、って書こうと思ったら、こちらもとてもきれいにまとめてくださっている投稿がありました。

最小権限のアカウントを使う

ここまでで見ていただいたマネージドIDとサービスプリンシパルは、いずれもユーザー名/パスワードを入力しなくても管理作業ができる仕組みでした。でも、それってアクセストークンやクライアントシークレットなどの情報が盗まれたら危険なのでは？という心配もありますが、マネージドIDやサービスプリンシパルは特定のサービスでしか利用できないIDであるという点で一定の安全性は担保されているわけです。
それに対してマネージドIDやサービスプリンシパルが利用できない環境がある場合、仕方がないんで、ユーザー名とパスワードを使ってください。その場合、管理作業を行うために必要な最小権限のロールを割り当てるようにしてください。例えば、Connect-AzureADコマンドレットでユーザーを作成するときにグローバル管理者のロールって必要ですか？そんなわけないですよね。

■ ■ ■

ここまでのところで、Azure ADで管理権限を利用した管理作業の方法について見てきました。単純にユーザー名とパスワードを使うだけじゃない管理方法も覚えて、より安全な管理を心がけたいですね。

皆さんこんにちは。国井です。

今日はAzure ADの条件付きアクセスの話です。
条件付きアクセスの存在を知り、ある程度条件付きアクセスのことについてわかってくると
お客さんから必ず聞かれることがあります。

条件付きアクセスで証明書認証できないの？

Microsoft Cloud App Security (MCAS) を使えば可能です。
(条件付きアクセスを利用した証明書認証って、表現として正しくない気がしますが、
細かいことは言いっこなしでお願いします)

条件付きアクセスにはアクセスを許可/拒否するアクセス制御設定とは別に、
[セッション]と呼ばれるアクセス制御設定があり、これを利用するとExchange  OnlineやSharePoint Online、MCASのアクセス制御機能と連携したアクセス制御が実現できます。これにより、特定のクラウドサービスにアクセスしてくるユーザーが証明書を持っているか？をMCASで判定させておいて、その結果に基づいて条件付きアクセス(とMCAS)を利用してアクセス制御することができます。

では設定方法を見てみましょう。

条件付きアクセスの設定

MCASで証明書を持っているかをもとにした判定を行う場合、アクセスポリシーと呼ばれるポリシーを作るのですが、アクセスポリシーは条件付きアクセスを事前に設定していることが条件になります。条件付きアクセスでは、次のようなポリシーを作りました。

■ユーザーとグループ：すべてのユーザー
■クラウドアプリ：SharePoint Online
■セッション：アプリの条件付きアクセス制御を使う – カスタムポリシーを使用する

設定できたら、ポリシーを有効化しておきましょう。
これでSharePoint Onlineをターゲットにしたポリシーができました。

MCASで認証局を登録

続いてMCASの設定です。ポータルサイトから[設定]画面にアクセスし、[デバイスの識別]にアクセスします。
すると、[クライアント証明書ベースの識別] 欄から認証局の情報が登録できます。
認証局の情報は認証局のルート証明書を登録することで設定できます。
ちなみに、下の画面ではcontoso.comドメインのCAのルート証明書を登録しました。

認証局であれば、パブリックCA、プライベートCAどっちでもOKなのがありがたい。
そういえば、ゼロトラストのオライリー本にもプライベートCA使えって書いてありましたね。

アクセスポリシーの作成

続いてMCASからアクセスポリシーを作成します。
MCASのアクセスポリシーとは名前のとおり、クラウドサービスに対するアクセスを制御するためのポリシーで具体的にアクセスを制御する条件を設定します。ここでは、「デバイスが有効なクライアント証明書を持っていなかったら」という条件を設定し、アクションとして「テスト」としておきました。
(ブロックを選べばブロックされますが、まずはテストで確認しましょうね)

アクセスしてみる

ここまでで設定は完了。
実際に証明書を持っていないユーザーがSharePoint Onlineにアクセスすると、アクセス自体はできましたが、MCASで以下のようなアラートが出力されました。

ちなみにアクセスポリシーのアクションをテストからブロックに変えてアクセスしてみると、ご覧のようにブロックされます。

一方、MCASに登録した認証局から発行した証明書を持っているユーザーがSharePoint Onlineにアクセスすると、ご覧のように「あなたが使う証明書、これで良い？」という確認画面が出てきて、OKをクリックすると、

問題なくSharePoint Onlineにアクセスできました。
ちなみに、ここで使う証明書は特定の認証局から発行された証明書であればOKなので、
ユーザー証明書(デバイスではなく)でもOKです。

証明書認証ができるならIntuneいらなくね？

条件付きアクセスにはIntuneにデバイスが登録されていることを基準にアクセス制御する方法があるので、証明書認証でアクセス制御できるなら代替できるのではないか？という疑問もあるでしょう。
しかし、それは2つの理由で「それは違う！」と言えます。

ひとつはIntuneの持つ機能です。
Intuneを使った条件付きアクセスはデバイスが登録されているかだけでなく
コンプライアンスポリシーを使って

特定OSバージョンのみ許可
BitLockerを有効化しているときだけ許可

のような追加条件が入れられるので、その点で単純に証明書認証をするのとは違うと思います。もっと言えばIntuneを使う理由って条件付きアクセスだけじゃないですよね？

もうひとつはコストです。
条件付きアクセスはAzure AD Premium P1(650円)のライセンスが必要ですが、
MCASを使うことになればMCASのコスト(380円)もかかってきます。
それに対してAzure AD Premium P1 + Intuneの組み合わせであればEMS E3(960円)で両方使えるので、EMS使ったほうが安くなってるんですよね。
(※どうやって購入するかによって値段は変わってくるので、必ずしもこれが正しいとは言えないという言い訳だけ先にしておきます)

ただ、MCASもまた証明書認証のためだけに使うものじゃないので、結局は何をやりたいか？で買うものって決まるんですよね。

証明書認証の是非を考える

この話を突き詰めると、そもそも証明書認証ってどうなの？という話になります。
人によっていろいろな意見があるでしょうし、私の一方的な立場を表明して炎上するのも嫌なので(笑)マイルドな表現にとどめておきますが、少なくともマイクロソフトさんの中では証明書ありきのセキュリティ対策をビジョンとして掲げていないように思います。
実際、Intune登録デバイスのみアクセスを許可する、Windows Hello for Businessで認証する、FIDO2デバイスで認証する、などの最近の流れを見ればわかるように、証明書をむき出しで使うようなやり方はしていないわけです。
(※この話をしていて、あるお客さんの会社でWPA EnterpriseのWi-Fiが導入されていて、証明書を入れなきゃいけないんだけど、面倒くさいからPFXファイルを直接インストールするってやり方をしている話を思い出しました)
どこの会社のクラウドサービスを選ぶかはそれぞれの会社次第ですけど、マイクロソフトのクラウドサービスを選択するのであれば証明書認証は永続的な認証方法として選択するべきじゃないと思います。
勝手な想像でしかないけど、証明書を認証基盤の中心に据えていると、いつかハシゴを外されるような気がして怖い.. その意味でも証明書認証は他の認証(というかアクセス制御)を導入するまでのつなぎと考えておくのが吉かと思います。

皆さんこんにちは。国井です。

このブログを書いている今日(2020年4月10日)はCOVID-19の影響でリモートワークに切り替えている方も多いと思います。リモートワークに切り替えるIT Guyが増えるとブログのPVが減るって現象、私だけなんですかね？

■ ■ ■

多要素認証(MFA)はセキュリティのことを考えれば、もはや必須のテクノロジーだと思いますが、会社の中で利用開始するためには電話番号を登録する、Microsoft Authenticatorアプリでアカウントのマッピング設定を行う、などの初期設定をしなければなりません。
しかし、その登録は社内で行いたいというニーズは一定数あります。例えば「Azure ADのアカウントを外出先で使うのは構わないけど、初期設定だけは必ず社内で行ってほしい」のようなニーズです。

その場合、条件付きアクセスの[セキュリティ情報の登録]を利用すれば実現できます。

MFAの有効化

まずはMFAを有効化しておきましょう。
MFAの有効化はAzure AD管理センターのユーザー画面から設定してもいいですし、条件付きアクセスで設定してもよいでしょう。

MFAの登録場所の定義

[セキュリティ情報の登録]設定を利用するときは、

1．MFAの登録場所を[ネームドロケーション]設定でIPアドレスの定義
2．[条件付きアクセス]設定で登録場所以外の場所からアクセスしようとした場合にはブロックする設定

をそれぞれ行います。
まず、[ネームドロケーション]設定はAzure AD管理センター画面で、[サインイン]-[ネームドロケーション]からIPアドレスを登録します。
IPアドレスの登録はCIDR形式で入力する必要があるので、例えば社内からのアクセスのみ許可という設定をする場合であれば、社内のグローバルIPアドレスを確認したうえで、グローバルIPアドレスが1.2.3.4であれば、1.2.3.4/32のように入力します。

続く[条件付きアクセス]設定はAzure AD管理センター画面で、[サインイン]-[条件付きアクセス]から登録します。条件付きアクセスポリシーは以下のようなパラメーターで設定します。

■ユーザーとグループ：すべてのユーザー
■クラウドアプリまたは操作：ユーザーの操作/セキュリティ情報の登録
■条件：場所/対象-すべての場所/対象外-ネームドロケーションで作成した場所
■許可：アクセスのブロック
■ポリシーの有効化：オン

ここまでの設定ができれば準備完了です。
※このときに注意したいのは上の設定で対象を[すべてのユーザー]としましたが、いきなりすべてのユーザーで設定するべきではありません。設定をしくじったときに誰もAzure ADにサインインできなくなる可能性があるからです。
必ず最初は一部のユーザーだけを登録してテストしてください。

実際にアクセスしてみる

まずは社外からアクセスしてみます。ユーザー名とパスワードを入力し、サインインに成功した後、ご覧のような画面で、先にはアクセスできなくなります。予定どおりですね。

続いて社内からのアクセス。前と同じようにユーザー名とパスワードを入力し、サインインに成功すると、MFAの登録画面が登場します。
ちなみに下にあるMFAの登録画面、URLが https://aka.ms/setupsecurityinfo になっていて、これまでにMFAの登録に使っていた https://aka.ms/mfasetup とは異なる画面になっています。
今までの画面との大きな違いは https://aka.ms/setupsecurityinfo から登録した場合、MFAの登録とセルフサービスパスワードリセット機能のパスワードリセット用電話番号の登録が同時にできる点にあります。

登録画面では、Microsoft Authenticatorのアプリを入れるように促され、iOSまたはAndroidでアプリを入れたら、次へ進んで、

QRコードの読み取り画面が出てくるので、アプリからQRコードを読み取ると登録は完了です。

続いて電話番号の登録も要求されます。これはセルフサービスパスワードリセット機能で使われるほか、Microsoft Authenticatorアプリが付かなかった時のMFAの代替手段として登録しておくものです。

それぞれの登録が完了すると、MFAの登録は完了です。
これ以降は、社内・社外関係なくAzure ADのサインインができるようになります。

ちなみになんですが、登録が完了した後で社外から https://aka.ms/setupsecurityinfo にアクセスしたら見事にブロックされました。つまり、条件付きアクセスの[セキュリティ情報の登録]機能って、単なる https://aka.ms/setupsecurityinfo サイトへのアクセス制御機能だったんですね。

そもそも社内は信頼できる場所なのか？

「社内から●●したい」という話はよく聞く話です。今回、ここに書いた話もそのひとつです。ただ、ここまで書いておいてアレなんですけど、「初期設定を社内で行いたい」という発想は社内なら安全という考えに基づくものだと思います。業務の都合上、会社に出向くことが難しいという声はよく聞きますし、この投稿を書いている今はCOVID-19の影響でそもそも会社に行けなくなっていることを考えると、場所をベースに●●するという考えを改める良いきっかけになるのではないかと思います。
今回は場所をベースにするというポリシーで条件付きアクセスを設定しましたが、条件付きアクセスの[セキュリティ情報の登録]機能を利用するのであれば、例えばデバイスが安全であることを担保した上で登録を許可する、のような運用のほうがいまどきなように思います。

■参考情報
https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/howto-registration-mfa-sspr-combined
https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/concept-registration-mfa-sspr-combined

皆さんこんにちは。国井です。

今日はお知らせです。Microsoft 365 E5等のライセンスを通じて利用可能なMicrosoft Threat Protectionシリーズのうち、Office 365 ATP, Microsoft Defender ATP, Azure ATPの初期設定を行う方法を解説した環境構築編と、Office 365 ATPの利用方法を解説したOffice 365 ATP 攻撃検証編がそれぞれリリースされました。

▼Microsoft Threat Protection 評価ガイド 環境構築編
https://aka.ms/mtp-evalguide-setup

▼Microsoft Threat Protection 評価ガイド Office 365 ATP 攻撃検証編
https://aka.ms/mtp-evalguide-o365pb

Office 365 ATP 攻撃検証編ではメール内での悪意あるリンクやマルウェアの検出方法とその調査方法について解説しています。
特に、自動調査 (Auto IR) はマルウェアなどを検出したときに、その影響範囲を調査したり、似たような攻撃が行われていないかを調査したりするのに利用可能です。
過去にもこちらで紹介させていただきました。

また、自動調査で過去にやり取りのあったメールを追跡し、マルウェアの流通がどの程度あったか？などのアセスメントに使うこともできますので、セキュリティ対策として何をすればよいのか？というお悩みの方には第一歩として活用してもらえると思います。

コンピューターウイルスよりもリアルなウイルスのほうが恐ろしいタイミングではありますが、Office 365 E5の無料試用版さえ取得すれば、リモートワークの環境でもお試しいただけるので活用してみてください。

皆さんこんにちは。国井です。
以前、PowerShellでAzure ADを使うときにセキュリティの面から

$cred=Get-Credential
$cred.password | ConvertFrom-SecureString | Set-Content "password.dat"
$password = Get-Content c:\password.dat | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PsCredential "admin@xxxx.onmicrosoft.com", $password
Connect-AzureAD -Credential $credential

のようなことはやるべきでないと紹介しました。
もし、Connect-AzureADコマンドレットの認証を自動化させたいのであれば
証明書を利用して認証するように構成すると認証プロセスの自動化ができるので
このやり方を今日は紹介します。

アプリの登録の作成

証明書を利用してConnect-AzureADコマンドレットを実行するときに最初にやることは
[アプリの登録]を作成し、サービスプリンシパルをAzure ADの中に作っておくことです。

Azure AD管理センターから[アプリの登録]を新規作成します。Webアプリケーションではないので、名前だけ入力すればOKです(リダイレクトURIの指定は不要です)。
ここでは、アプリの登録の名前を「Graph API」としておきました。
続いてアプリの登録を利用するための証明書を登録します。
(Connect-AzureADコマンドレットではクライアントシークレットは使えません！)
証明書はコマンドレットを実行する予定のコンピューターで以下のコマンドレットを実行し、作成しておいてください。

##
## Create self signed certificate
##
$cert = New-SelfSignedCertificate -Subject "CN=SelfSignedCert" -CertStoreLocation "Cert:\CurrentUser\My"  -KeyExportPolicy Exportable -KeySpec Signature
$cert
##
## Export new self signed certificate as .cer file
##
$cerfile = ".\SelfSignedCert.cer"
Export-Certificate -Cert $cert -FilePath $cerfile

以上により出来上がったSelfSignedCert.cerファイルを開き、拇印の値を[アプリの登録]-[証明書とシークレット]の[証明書のアップロード]をクリックして、登録してください。

サービスプリンシパルの確認

[アプリの登録]から作成したサービスプリンシパルの実体はエンタープライズアプリケーションに作られます。
Azure AD管理センターの[エンタープライズアプリケーション]からGraph APIの名前を付けたエンタープライズアプリケーションにアクセスし、
オブジェクトIDとアプリケーション IDを確認しておいてください。

サービスプリンシパルにユーザー管理者ロールの割り当て

サービスプリンシパルを使ってConnect-AzureADコマンドレットの認証を行った場合、サービスプリンシパルの権限でPowerShellを操作することになるので、
サービスプリンシパルにユーザー管理者ロールを割り当てておく必要があります。ただし、ロールの割り当て画面からはサービスプリンシパルに割り当てができないのでPowerShellから割り当てを行う必要があります。
グローバル管理者で一度、Connect-AzureADコマンドレットで接続し、

Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq "User Account Administrator"}
$Role = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq "User Account Administrator"}
Add-AzureADDirectoryRoleMember -ObjectId $Role.ObjectId -RefObjectId <サービスプリンシパルのオブジェクトID>

以上を実行すれば、サービスプリンシパルにユーザー管理者のロールを割り当てできます。
(※私のテナントではグローバル管理者をユーザー管理者ロールに入れないとコマンドレットが実行できない現象がありました)

いよいよ接続

ここまでで準備は完了です。実行してみましょう。

$cert = Get-ChildItem -path cert:\CurrentUser\My | Where-Object {$_.Thumbprint –eq <証明書の拇印>}
Connect-AzureAD -CertificateThumbprint $thumprint -TenantId $tenantId -ApplicationId <エンタープライズアプリケーションに登録されたアプリの登録のアプリケーションID>

これでPowerShellでAzure ADを操作できるようになりました。
アプリの登録を使ってAPIアクセスするときはAPIアクセス許可を割り当てて運用しますが、
Connect-AzureADコマンドレットの場合はロールとして何が割り当てられているかでPowerShell内でできることが決まります。
そのため、サービスプリンシパルをロールに割り当てるという作業が必要になるのです。

次回、PowerShellでちょっとしたことを行うのですが、そのときに必要になるテクニックなので、覚えておいてください。

皆さんこんにちは。国井です。

Azure ADユーザーに対して、Office 365やMicrosoft 365のライセンス割り当てを行うときって必ずあると思います。そのときユーザーひとりずつ割り当てを行うのは面倒なので、Azure AD Premium P1のライセンスを持っているテナントであれば、グループにライセンス割り当てをしておいて、ユーザーはそのグループのメンバーになれば、自動的にユーザーに対してライセンス割り当てができると思います。

ただし、この機能はAzure AD内部で[再処理]というプロセスが実行されたときに割り当てられるので、だいたい1時間ぐらいのタイムラグが生じます。(もちろんグループのプロパティで[再処理]ボタンを押せばよいのですが、それを行うのが面倒って場合もあるでしょう)

グループの[再処理]ボタンを押すって処理、PowerShellでやりたいと思ってスクリプトを作ろうとしたら意外に大変なのね..

ってことで今日はその備忘録を残しておきます。
全部の手順を書くとめっちゃ大変なので、一部設定は他の投稿を引用しながら進めます。

なぜ大変なのか？

Azure AD PowerShell コマンドレットに[再処理]ボタンを押すオプションがありません。
そのため、Microsoft Graph経由での操作になるのですが、グループに対する[再処理]を実行するAPIはなく、ユーザー単位で[再処理]を実行するAPIを呼び出さなければならないのです。

ただ、このボタンを押したいだけなのに。

Microsoft Graph経由で再処理を実行

Graphを実行するための [アプリの登録] を作成します。
(※アプリの登録の作成方法はこちらで解説しています)
アプリの登録でアクセス許可を与えるAPIは
・Directory.ReadWrite.All
・User.ReadWrite.All

の2つです。どちらもアプリケーションのアクセス許可として割り当ててください。

PowerShellスクリプトの作成と実行

こちらのPowerShellスクリプトも以前の投稿、[Microsoft Graph APIでAzure ADを管理]から流用しました。
ポイントを解説すると、
まず最初の5行にあるパラメーターは
$tenantId の項目に Azure AD のテナント ID
(Azure AD 管理センターのトップページで確認できます)
$clientID の項目に[アプリの登録]を作成すると生成されるクライアントID
(アプリの登録ページで確認できます)
$thumbprint の項目にアプリの登録に登録した証明書の拇印
(証明書の作り方・登録方法についてはこちらで解説しています)
$serviceprincipal の項目にはアプリの登録に対応するエンタープライズアプリケーションのオブジェクトID
をそれぞれ入力してください。

また、最後のほうにある Invoke-RestMethod コマンドレットですが、
ここが再処理を実行しろ！という命令をしているところです。

Invoke-RestMethod -Uri "$resource/v1.0/users/<ユーザーのオブジェクトID>/reprocessLicenseAssignment" –Method POST -Headers $headerParams -ContentType "application/json"

ユーザーのオブジェクトIDはGet-AzureADUserコマンドレットを使えば取得できるので、Connect-AzureADコマンドレットをあらかじめ実行し、その上でGet-AzureADUserコマンドレットを実行して、それぞれのユーザーのオブジェクトIDを取得し、それぞれのユーザーで再処理を行うよう、ForEach コマンドレットを使ってループ実行します。

ここまでができると、ユーザーはライセンス割り当てされたグループのメンバーであれば、即座にユーザーに対するライセンス割り当てが完了します。
これをひとまとめにしたPowerShellスクリプトがこちら。

##
## Authorization & resource Url
##
$tenantId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$resource = https://graph.microsoft.com
$clientID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$thumbprint = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
$serviceprincipal = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

##
## Download NuGet.exe
##
$sourceNugetExe = "https://dist.nuget.org/win-x86-commandline/latest/nuget.exe"
$targetNugetExe = ".\nuget.exe"
Remove-Item .\Tools -Force -Recurse -ErrorAction Ignore
Invoke-WebRequest $sourceNugetExe -OutFile $targetNugetExe
Set-Alias nuget $targetNugetExe -Scope Global -Verbose

##
## Download Microsoft.IdentityModel.Clients.ActiveDirectory.dll
##
./nuget install Microsoft.IdentityModel.Clients.ActiveDirectory -O .\Tools
md .\Tools\Microsoft.IdentityModel.Clients.ActiveDirectory
$prtFolder = Get-ChildItem ./Tools | Where-Object {$_.Name -match 'Microsoft.IdentityModel.Clients.ActiveDirectory.'}
move .\Tools\$prtFolder\lib\net45\*.* .\Tools\Microsoft.IdentityModel.Clients.ActiveDirectory
Remove-Item .\Tools\$prtFolder -Force -Recurse

##
## Remove NuGet.exe
##
Remove-Item nuget.exe

##
## MS Graph Access
##
Add-Type -Path ".\Tools\Microsoft.IdentityModel.Clients.ActiveDirectory\Microsoft.IdentityModel.Clients.ActiveDirectory.dll"

##
## Authorization & resource Url
##
$authUrl = "https://login.microsoftonline.com/$tenantId/"

##
## Create AuthenticationContext for acquiring token
##
$authContext = New-Object Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext $authUrl, $false

##
## Create credential for client application
##
$clientCred = New-Object Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredential $clientID, $clientSecret

##
## Acquire the authentication result
##
$authResult = $authContext.AcquireTokenAsync($resource, $clientCred).Result

##
## Give User Account Administrator permission to service principal
##
Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq "User Account Administrator"}
$userAdminRole = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq "User Account Administrator"}
Add-AzureADDirectoryRoleMember -ObjectId $userAdminRole.ObjectId -RefObjectId $serviceprincipal

##
## Get users data
##
Connect-AzureAD  -CertificateThumbprint $thumprint -TenantId $tenantId -ApplicationId $serviceprincipal
$users=Get-AzureADUser

##
## Execute Reprocess
##
ForEach($userObj in $users.ObjectID) {
$headerParams = @{'Authorization' = "$($authResult.AccessTokenType) $($authResult.AccessToken)"}
Invoke-RestMethod -Uri "$resource/v1.0/users/$userObj/reprocessLicenseAssignment" –Method POST -Headers $headerParams -ContentType "application/json"
}

もうめちゃくちゃ面倒！
だったら、Azure AD管理センターに行って、グループのライセンス項目にある[再処理]ボタンを押すわ！というのがお分かりいただけたと思います。

皆さんこんにちは。国井です。

以前、Azure ADではAU (Administrative Unit) という名のOU的なものが作れますよ、という話をしました。

「OU的なもの」って言い方をするのには理由があります。
Active Directoryの時代、OUを作成する目的は次の2つでした。

1．ユーザー/グループを分類し、
     特定OUの中だけの部分的な管理ができるようにしたい
2．グループポリシーを割り当てる単位として利用したい

AUは1.の目的で利用することができるけど、Azure ADではのグループポリシーの機能はないので、2.の目的で利用することができません。そのため、AUとOUは全く同じものではないけれど、少なくとも1.で行っていたことをAzure ADでもやりたいという人には朗報でしょう。

1.を図で示すとこんな感じになると思います。

昔からとても望まれていた機能だったのですが、以前はPowerShellからすべての設定を行う必要があると解説しました。ところが最近になって、やっとGUIから操作できるようになりました！早速ですが、

1. AUの作成
2. AUのメンバーの定義
3. AUの管理者と管理権限の定義

のステップで行う作業を確認してみましょう。

1．AUの作成

AUの管理はAzure AD管理センターの[管理単位]から行います。

[追加]ボタンをクリックして、AUの名前を設定するだけ。簡単ですね。

2．AUのメンバーの定義

1.で作成したAUをクリックし、[ユーザー]または[グループ]をクリックすると、ユーザーまたはグループを追加できます。ユーザーをCSVファイルから一括登録する方法も利用できます。

3．AUの管理者と管理権限の定義

AUのメンバーを管理する管理者は1.で作成したAUから[ロールと管理者]の項目で設定します。AUの管理者となるユーザーに割り当て可能なロールはご覧のとおりです。
だから冒頭に書いた「AUの全体管理者」っていうのは実はできないんですね..

以上の設定を行い、ロールが割り当てられたユーザーでAzure AD管理センターにサインインするとAU内のユーザーに対するプロパティの変更や、ユーザーそのものの削除、ライセンス割り当てなどの操作が行えるようになります。

また、Microsoft 365管理センターからもドロップダウンリストボックスでAUを選択し、AU内のユーザー/グループに対する設定を行うことができます。

Azure AD管理センターの[すべてのユーザー]でユーザー一覧を見ると、従業員のユーザーだけでなく、ゲストユーザーなども入り乱れて目的のユーザーにアクセスするのに苦労することもあると思いますが、AUを使えばユーザー管理の面倒が劇的に改善すると思います。

■ ■ ■

一方、実際の運用を考えた場合、AUの単位は事業所だったり、会社・部署だったり、教育機関であれば、学校や学年、クラスといった単位で分類することになります。しかし、動的グループのようにユーザーの属性に合わせて自動的に、誰がどのAUに所属するかを設定してくれるような機能はないため、Windows PowerShellでAUのメンバーを登録するコマンドレット
Add-AzureADAdministrativeUnitMemberは使い方を覚えておくとよいと思います。

前述のブログページで紹介していますので、ぜひご参考ください。

皆さんこんにちは。国井です。

イルミネート・ジャパンさんで開催しているトレーニングコースですが、
ついにオンライン開催の手はずが整いましたので、5月11-13日に開催予定のAzure ADコースよりオンラインで提供することにいたしました。

色々なディスカッションを通じて様々な知識を身に着けていただくコースなのに、オンラインで開催してよいものだろうか？というのは結構悩みました。そのおかげで4月の開催は中止させていただき、色々な方にご迷惑をおかけしてしまいました。しかし待っている方のためにいつまでも中止にすることはできないと思い、オンラインでの開催に踏み切ることにいたしました。

今後のトレーニングをすべてオンラインで開催するかについては世の中の情勢次第ですが、集合研修ができない今はひとまずオンラインで開催することといたしました。開催までにはまだ時間もありますので、ご興味のある方は受講をご検討いただければと思います。

皆さんこんにちは。国井です。

日本時間の2020年5月28日午前1時から36時間連続で開催されるオンラインイベント、
Microsoft 365 Virtual Marathonに私も参加することになり、
条件付きアクセスのセッションを受け持つことになりました。

私のセッションは「失敗しない条件付きアクセスの実装」というタイトルで、

2020年5月28日19:00から50分のセッションになります。

コロナ禍でなかなか外出できない状況が続いていますが、
こういう時こそ色々な知識を蓄えるチャンスととらえている方もいらっしゃるでしょう。
(実際、あるe-Learningサイトでは過去最高の視聴数だったりするそうです)

そこで、Azure ADで利用可能な条件付きアクセスをご利用いただく際に
注意いただきたいポイントなどを基礎から学んでいただけるような内容にしました。

19:00からというテレビで言えばゴールデンタイムなので、
テレビでも見るような感覚で、夕食をいただきながら、酒でも飲みながら、
気軽にご受講いただければと思います。

公式サイトから申し込みができますので、ぜひご参加ください(入場無料)

皆さんこんにちは。国井です。
2020年5月28日にMicrosoft 365 Virtual Marathonが開催され、私も条件付きアクセスのセッションを受け持たせていただきました。

その中でOffice 365に対する条件付きアクセスを設定する場合は個別のサービスではなく、Office 365全体に対してアクセス制御を行うようにポリシーを作るべきだという話をしました。理由はOffice 365で提供するサービスには依存関係が存在するからで、有名なところではMicrosoft TeamsがバックグラウンドでExchange OnlineやSharePoint Onlineを使うなどの依存関係があります。

こうした依存関係はOffice 365のあらゆるところに張り巡らされていて、それを踏まえて条件付きアクセスを設定するのが難しいからです。だって、Microsoft FormsがExchange Onlineに依存したサービスだなんて想像もできないですよね？

なのでOffice 365の個別のサービスに対して条件付きアクセスを設定するときは、マイクロソフトのWebサイトで依存関係を解説しているドキュメントがあるので、事前に確認しておくことをお勧めします。

先ほど例でMicrosoft FormsがExchange Onlineに依存したサービスだという話をしましたが、条件付きアクセスでExchange Onlineをブロックするように設定すると、Microsoft Formsは使えなくなります。
※そういえばVirtual Marathonのセッションのとき、「Formsの条件付きアクセスポリシーを作るとExchangeにアクセスできなくなる」って言いましたが、正しくは「Exchangeの条件付きアクセスポリシーを作るとFormsにアクセスできなくなる」でしたね。

じゃあ、Exchange Onlineを条件付きアクセスポリシーでブロックするように設定したら、オンライン予約のサービスであるBookingsがブロックされるかというと、そうじゃなかったりするんですね(Bookingsって思いっきりExchange Onlineの予定表使ってるのに！)。
こんな感じで自分の勘を頼りにしていると痛い目を見させられたりするのです..
だから公式ドキュメントって大事ですね！

あ、あと、依存関係のドキュメントの中に「事前バインディング」と「遅延バインディング」というのがあります。これはいつの時点で条件付きアクセスによるアクセス制御が行われるか？ということを表しています。条件付きアクセスはAzure  ADからサービスにアクセスするためのトークン(アクセス トークン)が発行されるタイミングでチェックを行います。

条件付きアクセスポリシーでExchange Onlineへのアクセスをブロックしているケースで考えてみます。

Microsoft Teamsにアクセスするときは、TeamsにアクセスしたタイミングでExchange Onlineにアクセスするときのトークンをもらいに行きます。つまり、Teamsにアクセスしたタイミングで条件付きアクセスを使ってTeamsとExchangeの両方にアクセスできるかを確認します(これを事前バインディングと言います)。

それに対して、Office 365のポータルサイト (https://portal.office.com) にアクセスすると、Exchange Onlineのアイコンが表示されますが、実際にExchange Onlineにアクセスするまではトークンを取得しに行きません。つまり、Exchange Onlineへのアクセスをブロックするように条件付きアクセスが設定してあったとしても、Office 365のポータルサイトへのアクセスは問題なくできるのです(これを遅延バインディングと言います)。

■ ■ ■

最近ではSharePoint Onlineの設定とのコラボでファイルのダウンロードを禁止するポリシーを作ったりすることもできるので、個別のポリシーを禁止するのやめましょうとは言い切れない部分もあるのですが、少なくとも依存関係はきちんと理解しておく必要があります。

皆さんこんにちは。国井です。

Microsoft IntuneでWindows 10デバイスを登録するとき「特定ユーザーだけしかIntuneにデバイス登録できないようにしたい」というニーズってあると思います。
オンプレミスActive Directoryのドメイン参加設定をしたことのある人の感覚で言えば「Adminユーザーでドメイン参加させたい」という感じでしょうか。

「特定ユーザーだけしかIntuneにデバイス登録できないようにしたい」
この設定を行うには2つやることがあります。

ひとつはデバイス登録マネージャーというIntuneの設定
もうひとつは条件付きアクセスでデバイス登録の制限の設定

です。

デバイス登録マネージャー

デバイス登録マネージャー(DEM)とはAdminユーザーで無制限(っぽく)デバイス登録する機能です。通常、Intuneのデバイス登録は1ユーザーで15デバイスがライセンス上の上限なのですが、DEMを利用すると1ユーザーで1000デバイスまで登録できるようになるので、Adminユーザーで皆のデバイスをまとめて登録したいときに便利な機能です。
(Microsoft Endpoint Manager画面のデバイス > デバイス登録 > デバイス登録マネージャーから設定します)

条件付きアクセスでデバイス登録を制限

もうひとつの条件付きアクセスはAdminユーザーでまとめて登録すると決めたら、その他のユーザーで登録できないようにしたいというときに使います。
条件付きアクセスはAzure AD 管理センターの セキュリティ > 条件付きアクセスから、次のような感じで設定します。

・ユーザーとグループ：管理者以外のすべてのユーザー
・クラウドアプリ：Microsoft Intune
・アクセス制御：ブロック

ところがこの設定にはちょっとした問題があります。
クラウドアプリを登録するときに、
Microsoft IntuneとMicrosoft Intune Enrollmentがあるけど、どちらを使うの？です。

ということで、条件付きアクセスでMicrosoft IntuneとMicrosoft Intune Enrollmentをそれぞれ個別に設定してみましたら、Microsoft Intune Enrollmentだけが条件付きアクセスで利用可能でした。なので、管理者だけがIntuneのデバイス登録できるように条件付きアクセスを設定したい！という時は次のように設定してください。

・ユーザーとグループ：管理者以外のすべてのユーザー
・クラウドアプリ：Microsoft Intune Enrollment
・アクセス制御：ブロック

そうすると、管理者以外のユーザーでデバイス登録を行おうとすると次のようにブロックされます。

↓

↓

↓

参考までにデバイス登録に失敗した時のAzure ADのログはこんな感じ。
デバイス登録連携機能を使ってAzure ADとIntuneの登録を同時に行おうとすると、
Azure ADへのデバイス登録は成功するけど、

続くIntuneへのデバイス登録は失敗。

デバイス登録連携機能でAzure ADへのデバイス登録だけ成功して、Intuneへのデバイス登録に失敗した場合、Azure ADへのデバイス登録はキャンセルされて、どちらのデバイス登録も行われずに終了します。

■ ■ ■

話は少し外れますが、
Windows 10へのデバイス登録には、Azure ADへの登録とMicrosoft Intuneへのデバイス登録の2つが必要です。これが面倒なので、Azure ADにはAzure ADにデバイス登録すると自動的にIntuneにも登録するという連携機能があります。
連携機能の画面(Azure AD管理センター > モビリティ)を開くと、
ここにもMicrosoft IntuneとMicrosoft Intune Enrollmentの2つがあるのです。

実際、どちらの画面を開いても[MDMユーザースコープ]という連携のための設定が用意されていますし、どちらから設定しても同じ結果になるので、ますます、この2つの違いがわからない…

おまけ

最後にIntuneに登録されたデバイスの通信を条件付きアクセスでブロックしたいときは、
今度こそ条件付きアクセスで

・ユーザーとグループ：管理者以外のすべてのユーザー
・クラウドアプリ：Microsoft Intune
・アクセス制御：ブロック

って設定すればいいんじゃないの？と思いますが、これは失敗しました。
ですので、Intuneへのアクセスを社給デバイスだけにしたいなどの要望をいただくことがあるのですが、Intuneにデバイス登録されてからでは遅いので、登録するタイミングで不適切な登録プロセスがあれば、条件付きアクセスでブロックしてあげてください。
(推測ですけど、おそらくIntuneのチェックインプロセスには先進認証を使っていることが原因だと思います)

■参考情報 Intune へのデバイスの登録で多要素認証を要求する
https://docs.microsoft.com/ja-jp/mem/intune/enrollment/multi-factor-authentication

皆さんこんにちは。国井です。
今日はAzure ADを使い始めようと思った時に設定しておきたい項目をリスト化しておきます。一部、関連するリンクも貼り付けておきますので参考にしてください。
前提条件は既にOffice 365を契約していることです。

カスタムドメイン名

Office 365を既に使っているなら設定済みとは思いますが念のため。
カスタムドメイン名とはユーザー名の @ 以降の名前のこと。
既定ではxxxx.onmicrosoft.comだと思いますが、これを別の名前にできます。
メールアドレスとしても使う可能性があるから、普通は sophianetwork.co.jp のような会社のドメイン名にしてください。
Azure AD管理センター > Azure Active Directory > カスタムドメイン名から登録します。
登録するときに、画面で指示されたレコードをDNSサーバーに登録する必要があるので、
DNSサーバーにレコードが登録できる環境を用意してから行ってください。

ユーザーの作成

ユーザーは色々な作り方がありますが、ここではやり方は問いません。
先日、Microsoft 365 Educationがらみのお仕事で、CSVファイルからまとめてユーザーを作るというスクリプトに出会ったのですが、
これはなかなか良いと思います。

https://github.com/taando-msft/GIGA-Rapid-Deploy

上記サイトからファイルをダウンロードしたら C:\xxxxx フォルダー(フォルダー名はなんでもよい)にファイルを保存し、Windows PowerShellで次のコマンドレットを実行します。

Set-Location -Path C:\xxxxx
.\CreateCSV.ps1

C:\xxxxx\output フォルダーに CSV ファイルが出来上がるので、このファイルに従業員の情報を埋めましょう。

ファイルができたらc:\xxxxx フォルダーに CSV ファイルを保存しましょう。
次にCreateSchoolAccounts.ps1 ファイルを右クリックから編集で開いて、
以下の編集を行いましょう

設定が完了したら、BatchCreateSchoolAccounts.ps1 ファイルを右クリックし、管理者として実行します。このとき、InputSchoolDataCsv:と表示されるので、前の手順で作成したCSVファイルの名前を入力してください。

すると、CSVファイルに作ったユーザーがまとめて作成されます。
Microsoft 365 Education用に作られたスクリプトですが、一般企業でも使えるかなと思います。と、ここまでユーザー作成の話をしましたが、オンプレミス Active Directoryを保有している会社ではAzure AD Connectを利用してユーザーを作成てもよいでしょう。

グループの作成

ユーザーを作成したら、グループも作成しましょう。グループはアクセス許可を割り当てる単位になるので、例えば、部署単位、役職単位などでグループを作りましょう。
グループにはセキュリティグループとMicrosoft 365グループ (旧Office 365 グループ)がありますが、Microsoft 365グループを作ると、それに対応するMicrosoft Teamsのチームが作られ、グループのメンバーはチームへのアクセス許可が割り当てられます。
ですので、Microsoft Teamsの利用を考えている会社であれば、Microsoft 365グループでグループを作ると、Teamsのアクセス許可管理も簡単になります。
設定は Azure AD管理センター > Azure Active Directory > グループから

グローバル管理者の定義

グローバル管理者はふたり以上にロール割り当てしておくことがベストプラクティスです。
(ひとりだけだと、そのひとりがアクセスできなくなったときに誰もグローバル管理者の権限を使えなくなってしまうので)グローバル管理者の名前には、管理者とわかる名前を使うのはやめましょう。

設定は Azure AD管理センター > Azure Active Directory > ロールと管理者から

MFAの定義

多要素認証(MFA)は設定していない場合に比べて99%の不正アクセスの遭遇率低減というメリットがありますので、少なくとも管理者ロールが割り当てられたユーザーには設定しましょう。
設定はAzure AD管理センター > Azure Active Directory > ユーザー > Multi-Factor Authentication から対象となるユーザーを選択します。

緊急用グローバル管理者の定義

Break Glassアカウントとも呼ばれる緊急用グローバル管理者はグローバル管理者のロールが割り当てられたユーザーです。通常のグローバル管理者と異なるのは条件付きアクセスをひとつも割り当てない、MFAを設定しないことです。グローバル管理者なのにMFAを設定しなくて大丈夫？という意見がありますが、「緊急用」なので、普段使いはしないでください。そうすれば、サインインログから緊急用グローバル管理者による不正アクセスがあれば発見できるはずです。

会社のブランド設定

サインイン画面で会社のロゴを表示したり、背景に会社のブランドイメージになるような画像を配置することができます。(サンプルは↓こちら↓)

Azure AD管理センター > Azure Active Directory > 会社のブランドから設定します。
ロゴは280×60ピクセルの10KB以内、背景画像は1920×1080の300KB以内であることが必要です。1920×1080で300KB以内の画像を用意するのって結構大変なんですよね。
その場合は1920×1080よりも小さなサイズで画像を作っておいて登録するとよいですよ。
16:9の比率さえ守っていればOKです。

条件付きアクセスの設定

条件付きアクセスとはクラウドサービスに対するアクセス制御機能で、会社にとって好ましくないアクセスをブロックしてくれます。多要素認証を必須にするなどの設定を行えますが、ここで紹介したいのはレガシー認証のブロックです。
※レガシー認証については別の投稿で紹介します。
レガシー認証を有効にしていると、多要素認証が使えない、パスワードスプレー攻撃と呼ばれる攻撃を受ける可能性がある、などのセキュリティ上の問題があるので、無効にすべきとされています。設定はAzure AD管理センター > Azure Active Directory > セキュリティ> 条件付きアクセス よりポリシーを作成します。ルールはこんな感じで。

ユーザー：管理者を除く、すべてのユーザー
アプリ：Office 365
条件：クライアントアプリ > モバイルアプリとデスクトップクライアント > 他のクライアント
許可：ブロック

セキュリティの既定値群設定

Azure ADに関わるセキュリティ設定をまとめて実装してくれる設定です。
多要素認証を自動的に有効化してくれるなど、色々便利なんですけど、
この設定が有効になっていると条件付きアクセスの設定ができなくなるんですよね..
なので、私は無効にしています。(既定で有効な場合があるので注意！)
設定はAzure AD管理センター > Azure Active Directory > プロパティ > セキュリティの既定値群の管理よりどうぞ。

ユーザーによるポータルアクセスの禁止

管理者でないユーザーがAzure AD管理センターにアクセスできないようにしておきましょう。設定はAzure AD管理センター > Azure Active Directory > ユーザー設定 > Azure AD 管理ポータルへのアクセスを制限する を[はい]にしておきます。

ゲストの招待設定

社外のユーザーが私たちの作ったAzure ADに関連付けられたクラウドサービスにアクセスするときに使う設定です。(例えば、私たちの会社のTeamsに社外のユーザーを参加させるときとか、OneDrive for Business で作ったファイルを社外のユーザーと共有するようなケースです)
社外のユーザーを私たちの作ったAzure ADに入ってきてもらうときは「ゲストユーザー」というユーザーを作っておくのですが、これを作りたくないって場合があるんですよね。
そのときは Azure AD管理センター > Azure Active Directory > ユーザー設定 > 外部コラボレーションの設定を管理します
からゲストユーザーを利用できないようにしておきましょう。

パスワード期限切れポリシー

パスワードの定期的な変更については推奨しないのが今のご時世ですが、Azure ADでは既定で90日に一度パスワードの変更を要求します。設定を変更したい場合は https://admin.microsoft.com/AdminPortal/Home#/Settings/SecurityPrivacy よりパスワードの有効期限ポリシーを設定しましょう。

セルフサービスパスワードリセットの設定

ユーザーがパスワードを忘れた場合、あらかじめ登録しておいた携帯電話に電話をかけてきてもらうなどして本人確認を行い、その上で新しいパスワードを自分で再設定できるようにする機能があります。この機能を使えば、パスワードを忘れたって言ってアドミンに泣きつくっていう面倒くさいことを避けられます。
設定は Azure AD管理センター > Azure Active Directory > パスワード リセット から有効化します。
設定すると、ユーザーは次回サインインした時に携帯電話番号の登録を求められます。

デバイスの設定

コンピューターをAzure AD参加する場合、Azure AD参加の可否だったり、Azure AD参加時の管理者設定、移動ユーザープロファイル (Enterprise State Roaming) の設定などを行います。ざっくりな説明でごめんなさい！
設定は Azure AD管理センター > Azure Active Directory > デバイス > デバイスの設定 から行います。

■ ■ ■

【番外編】Microsoft 365 E5を契約

E5のライセンス高いよ！って声が聞こえるかもしれないけど、クラウドありきの社内インフラにするなら、E5もしくは別の会社の相応のサービスを契約するのが必要だと思います。(なんで必要か？という話は他で色々あるでしょうから、そちらに譲ります)
1ライセンスでいいから、とりあえず買いましょう。検証環境を作ったり、学習用環境を作ったりすることもあると思いますが、そのときによく聞くのが「無料試用版は30日で終わっちゃうから」。
Microsoft 365で範囲が広いので、本当にやることが決まっていなければ30日ですべての確認を済ませるのはそもそも無理だと思います。だからこそ1ライセンスでもいいので買って永続的に利用できる環境を用意しましょう。
会社が買ってくれないって？その場合は転職しましょう。

気が付いたことがあったら、追記していきますし、
これは必須じゃない？というのがあれば、いつでもご連絡ください。

皆さんこんにちは。国井です。
Windows 10をはじめとする、様々なコンピューターの挙動を監視し、不正アクセスの防御・検知・対応ができるEDRサービスである、Microsoft Defender ATPの評価ガイドが完成しました！
以下のWebサイトからダウンロードできますので、マイクロソフト製EDRに興味のある方、
これから評価してみようと思っている方はご覧になってみてください。

■Microsoft Threat Protection 評価ガイド　Microsoft Defender ATP 攻撃検証編

https://aka.ms/mtp-evalguide-mdatppb

Microsoft Defender ATPはMicrosoft Threat Protection (MTP) と呼ばれる、セキュリティソリューションの一部なんですが、MTPに含まれるOffice 365 ATPとAzure ATPのセットアップもまとめて検証していただけるガイドはこちらで提供しています。

▼Microsoft Threat Protection 評価ガイド 環境構築編
https://aka.ms/mtp-evalguide-setup

また、以前にもご案内させていただいたOffice 365 ATPのガイドも参考までに載せておきます。

▼Microsoft Threat Protection 評価ガイド Office 365 ATP 攻撃検証編
https://aka.ms/mtp-evalguide-o365pb

■ ■ ■

せっかくなので、Microsoft Defender ATPに登場する、特定のURLへのアクセスをブロックする機能について話を。
Microsoft 365を利用してURLアクセスのブロックを行う場合、次の2つの方法があります。

Intuneの管理用テンプレート プロファイルを利用

Microsoft Intuneの管理用テンプレートのプロファイルを利用する場合、

コンピューターの構成 > Microsoft Edge > URLのリストへのアクセスをブロックする

から設定します。

ただし、この方法はEdge (Chromium版) でしか使えないデメリットがあります。Microsoft 365 Educationの環境であれば、Edgeを使え！と学校で強制してしまえばそれで済む話ですが、企業の環境だと業務アプリケーションの関係でChrome出なきゃダメ！IEでなければダメ！などあると思います。
そういうときはMDATPとMCASを使います。

MDATP × MCASを利用

MDATP (Microsoft Defender ATP) にはオンボーディングしたデバイスのアクティビティからWebアクセスの情報を抽出し、MCAS (Microsoft Cloud App Security) で可視化するという連携設定があります。
これを利用すると、URLリストという無味乾燥なものではなく、クラウドサービスの名前で表示してくれます。

このリストはMCASのCloud Discoveryというサービスに反映されるのですが、Cloud Discoveryには承認されたアプリ、承認されていないアプリという設定があり、これを利用すると承認されていないアプリへのアクセスがあったらアラートを出す、などの設定ができます。
それで元々の課題であったアクセスをブロックする！についてですが、これはMDATPとの連携によって実現します。もうちょっと細かく言うと、MCASで承認されていないアプリの設定を行うと、

※承認されていないアプリの登録はアプリの名前の右側にあるボタンを押すだけ

その設定がMDATPの Settings > Rules > Indicatorsに登録され、

その情報がMDATPにオンボーディングされたデバイスに反映されることで、各デバイスで承認されていないアプリへのアクセスがブロックされます。

※会社のPCでNetflixを見る不届き者を締め上げってやった！

なお、この機能をIEとEdge以外で利用する場合はWindows Defender Exploit Guardに含まれるNetwork Protectionという機能を有効化する必要があります。Windows Defender Exploit GuardはグループポリシーまたはIntuneから有効化することができ(PowerShellでもOKです。評価ガイドに書いときました)、GPOなら

コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > Windows Defender ウイルス対策 > Windows Defender Exploit Guard > ユーザーとアプリが危険なWebサイトにアクセスするのを防ぎます をブロック

Intuneの場合は構成プロファイルから

Endpoint Protection > Windows Defender Exploit Guard > ネットワーク フィルター > ネットワーク保護 を有効

で設定できます。

今回はNetflixを例にブロックしましたが、会社のPCだったらgmailやdropboxをブロックして情報漏えいを防ぐなどのユースケースが考えられると思います。

■ ■ ■

今回リリースした評価ガイドではMicrosoft Defender ATPのサンプルを利用して検出や対応をひととおり見てもらっていますが、もう少し具体的なシナリオで使ってみたいなどあれば、対応するトレーニングをつくりましたので、ご検討いただければ幸いです。

皆さんこんにちは。国井です。

※以前の投稿でAzure ADのサインイン画面にしていた壁紙です。ご自由にお使いください。

イルミネート・ジャパン社との協業で開催している、
Microsoft 365関連コースの新しいスケジュールがリリースされました。

■Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編)
2020年9月7～9日
2020年11月4～6日

■Microsoft 365 を利用したインシデント対応
2020年7月27～28日
2020年10月5～6日

■EMS で実現するクラウド IT インフラ管理
2020年11月9～10日
2021年1月28～29日

各コース共にコロナウイルス対策で参加できる方の人数を少なくして対応させていただくのと同時に、7月からはオンラインでご受講いただけるコーススケジュールを新設しました。

■Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編)
– オンライン版
2020年10月19～20日
2020年12月1～2日

■Microsoft 365 を利用したインシデント対応 – オンライン版
2020年8月20～21日
2020年11月9～10日

移動によるリスクを避けたいという方だけでなく、遠方にお住いの方も参加しやすいようにしました。またオンラインのトレーニングでありがちなサポートが簡単に受けられない問題も、
コンテンツを少なめにしてひとつひとつの演習(ラボ)にじっくり取り組んでいただけるようにしました。

以下のページからコースの詳細はご確認いただけますので、ぜひご覧ください。

皆さんこんにちは。国井です。

アプリケーションからAzure ADのユーザー名/パスワードを入力してサインインしているだけなのに、その認証にはレガシー認証と先進認証と呼ばれる2つがあります。

レガシー認証はOffice 2013以前のOfficeアプリケーションやSMTP,POPなどを利用したアプリケーションなどで使われます。レガシー認証の実態は基本認証で、これを利用すると多要素認証が使えないなど、セキュリティ上の問題点が指摘されていることもあり、2021年後半に廃止される予定になっています。(もともとは2020年10月に廃止される予定だったのですが延期されました)

いずれにしてもレガシー認証が無くなることは確かなのに、自分のまわりからはレガシー認証無くすために〇〇しよう、みたいな話が聞こえてこないんですよね。
実際に自分の会社でレガシー認証を使っているかについて確認するときは
Azure ADのサインインログを使いましょう。

Azure AD 管理センター画面から [Azure Active Directory] – [サインイン] を開き、
フィルターで [クライアント アプリ]を選択して、

クライアントアプリの値としてレガシ認証クライアントの全項目を選択します。
(なるほど、ここに書いているアクセスがレガシー認証なのですね)

すると、レガシー認証を行った履歴が全部出てきます。
意外と出てくることがわかります。(しかも全部Exchange Onlineへのアクセス！)

なかでも多いのが、Exchange ActiveSyncを使って接続しているパターンと
アプリケーションパスワードを使って接続しているパターンでした。

Exchange ActiveSync

Exchange ActiveSyncは携帯電話からExchange Online/Exchange Serverに接続するときに使われるプロトコルでレガシー認証を使います。Exchange ActiveSyncを使うかどうかは携帯で使うメーラー次第なんだけど、iOSでも標準メーラーではExchange ActiveSyncを使っているようです。
(MSの中の人から標準メーラーは先進認証だという話をどこかで聞いたことがあるのですが、
私のログではiOS13の標準メーラーでもExchange ActiveSyncを使っていました)

アプリケーションパスワード

アプリケーションパスワードは多要素認証が使えない環境用(要するにレガシー認証用ってことですね)に用意された特別なパスワードで、これを利用すると多要素認証をスキップできます。アプリケーションパスワードはExchange ActiveSyncやPOP3/IMAP4などと一緒に使うことを想定しているようなので、結局レガシー認証になります。あ、ちなみにアプリケーションパスワードそのものについて詳しく知りたい場合はこちらをどうぞ。

アプリケーションパスワードを使ってサインインしているかについてはログの[認証の詳細]から[認証方法]欄を参照するとCloudOnlyPasswordと書かれているものがありますが、これがアプリケーションパスワードです(たぶん)。

■ ■ ■

私が面倒を見ている環境では、この2つがレガシー認証を使うことになる主要因でした。
いずれもExchange Onlineにアクセスするときの認証が要因なので、Exchange Onlineに接続するクライアントアプリの見直しを行うことにしました。

クラウド側の設定が要因であれば、管理者がちゃちゃっと設定すれば終わりなんだけど、
クライアント側の要因だと、各デバイスで設定をしなきゃならないので、時間をかけて入れ替えだったり、啓蒙活動だったりをしなきゃならないんですよね。

(続く)

皆さんこんにちは。国井です。

前回、Azure AD レガシー認証の見つけ方・やめ方(1)という投稿をしましたが、その続きです。前回はレガシー認証を見つけるときにはAzure ADのサインインログにフィルターをかけてレガシー認証のログだけが表示されるようにしましょうという話をしました。そして、その中でExchange ActiveSyncとアプリケーションパスワードを使った認証が多いという話をしました。
しかし、Exchange ActiveSyncとアプリケーションパスワードを使った認証が多いのは私が面倒を見ている環境の話であって、ほかの企業ではそうでもないかもしれません。
そこでレガシー認証の種類として何が使われているか、調べる方法について深掘りしてみたいと思います。

Log Analyticsを利用してレガシー認証を見つける

Log AnalyticsはMicrosoft Azureのサービスで、様々なログの格納とクエリによる分析ができます。Azure ADサインインのログをLog Analyticsへ持っていくと、そこからクエリを実行することで様々な分析ができます。Microsoft Azureの契約は必要になりますけど、クラウドなのでとりあえず使ってみて「やっぱり要らない」ということであれば削除しちゃえば良いのです。では設定していきましょう。

まず、Azure AD管理センターの [診断設定] メニューから診断設定を新規作成します。
このとき、logの種類としてSigninLogs、宛先としてLog Analyticsへの送信をそれぞれ選択します。
(※宛先としてLog Analyticsを選択するときは、Microsoft Azureの契約を済ませていること、そしてLog Analyticsのワークスペースを作成しておくことが前提条件になります)

設定が完了したら、しばらくするとLog Analyticsに保存されたデータからクエリを実行して分析を始められます。Log AnalyticsのクエリにはKQLと呼ばれる書式のクエリを使いますが、とりあえず使い始めたい人にはクエリを知らなくても使えるAzure AD管理センターの[Workbooks]メニューがおすすめです。

最初から色々なクエリが入ったレポートが用意されているので、クリックするだけで使えます。例えば、[レガシ認証を使用したサインイン]をクリックするとレガシー認証の構成要素が確認できます。今見ている環境ではExchange ActiveSyncを使ったアクセスとPOP3を使ったアクセスがそれぞれあることがわかります。

せっかくOffice 365 E3を買ってあげてるのに誰だよ、Outlook使わない人は.. というときはPOP3の項目をクリックします。すると、画面右側にユーザーと(ざっくりとした)アクセス日時が確認できます。

上の画面の右上にLog Analyticsボタンがありますが、これをクリックするとレポートに出ている内容をLog Analytics画面でクエリを実行した結果を表示してくれます。

POP3ユーザーが使っているアプリを特定したいと思ったらuserAgentを参照すればよいと思いつく方もいると思います。その場合、もともとのクエリがこちらですが、

let details = dynamic(
{
"Id":"Office 365 Exchange Online/POP3","Name":"POP3","Type":"Protocol","Sign-in Count":9,"Trend":"[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,1,0,0,2,1,0,0,2,1,0,1,0]","Failure Count":0,"User Interrupted Count":0,"ParentId":"Office 365 Exchange Online"});
let data = SigninLogs
|where AppDisplayName in ('*') or '*' in ('*')
|where UserDisplayName in ('*') or '*' in ('*')
|extend errorCode = toint(Status.errorCode)
|extend SigninStatus = case(errorCode == 0, "Success", errorCode == 50058, "Interrupt", errorCode == 50140, "Interrupt", errorCode == 51006, "Interrupt", errorCode == 50059, "Interrupt", errorCode == 65001, "Interrupt", errorCode == 52004, "Interrupt", errorCode == 50055, "Interrupt", errorCode == 50144, "Interrupt", errorCode == 50072, "Interrupt", errorCode == 50074, "Interrupt", errorCode == 16000, "Interrupt", errorCode == 16001, "Interrupt", errorCode == 16003, "Interrupt", errorCode == 50127, "Interrupt", errorCode == 50125, "Interrupt", errorCode == 50129, "Interrupt", errorCode == 50143, "Interrupt", errorCode == 81010, "Interrupt", errorCode == 81014, "Interrupt", errorCode == 81012 ,"Interrupt", "Failure")
|where SigninStatus == '*' or '*' == '*' or '*' == 'All Sign-ins'
|extend Reason = tostring(Status.failureReason)
|extend ClientAppUsed = iff(isempty(ClientAppUsed)==true,"Unknown" ,ClientAppUsed)
|extend isLegacyAuth = case(ClientAppUsed contains "Browser", "No", ClientAppUsed contains "Mobile Apps and Desktop clients", "No", ClientAppUsed contains "Exchange ActiveSync", "Yes", ClientAppUsed contains "Unknown", "Unknown", "Yes")
|where isLegacyAuth=="Yes"
| where AppDisplayName in ('*') or '*' in ('*')
| where details.Type == '*' or (details.Type == 'App' and AppDisplayName == details.Name) or (details.Type == 'Protocol' and AppDisplayName == details.ParentId and ClientAppUsed == details.Name);
data
| top 200 by TimeGenerated desc
| extend TimeFromNow = now() - TimeGenerated
| extend TimeAgo = strcat(case(TimeFromNow < 2m, strcat(toint(TimeFromNow / 1m), ' seconds'), TimeFromNow < 2h, strcat(toint(TimeFromNow / 1m), ' minutes'), TimeFromNow < 2d, strcat(toint(TimeFromNow / 1h), ' hours'), strcat(toint(TimeFromNow / 1d), ' days')), ' ago')
| project User = UserDisplayName, ['Sign-in Status'] = strcat(iff(SigninStatus == 'Success', '', ''), ' ', SigninStatus), ['Sign-in Time'] = TimeAgo, App = AppDisplayName, ['Error code'] = errorCode, ['Result type'] = ResultType, ['Result signature'] = ResultSignature, ['Result description'] = ResultDescription, ['Conditional access policies'] = ConditionalAccessPolicies, ['Conditional access status'] = ConditionalAccessStatus, ['Operating system'] = DeviceDetail.operatingSystem, Browser = DeviceDetail.browser, ['Country or region'] = LocationDetails.countryOrRegion, ['State'] = LocationDetails.state, ['City'] = LocationDetails.city, ['Time generated'] = TimeGenerated, Status, ['User principal name'] = UserPrincipalName

最終行の | project で始まる部分がクエリの結果として何を表示するか(SQLでいうSELECTの部分です)を表すところなので、これをカスタマイズして

| project User = UserDisplayName, [‘userAgent’] = UserAgent

と変更してみると

ご覧のような結果が出てきました。だけどBAV2ROPCってなに？？
(ちなみにIMAP4アクセスだとCBAInPRODってログがでます)
あまり役に立たなかったですね..

あとは最初に登場したクエリの最後の行に

| where SigninStatus != ‘Success’

と入れておけば成功しなかったログを検索できます。
POP3/IMAP4を使った不正アクセスって最近多いと聞きますが、こうした不正アクセスの試行があったかを確認するのにも使えます。

その他、AuthenticationDetails 内のauthenticationMethod項目を使えば、アプリケーションパスワードを表すCloudOnlyPasswordの文字列が書いてあるので、
それを使ってアプリケーションパスワードの利用状況を調べたりできます。

条件付きアクセスを使う

Azure ADの条件付きアクセスで [レポート専用] というモードがあります。これを使って、以下のようなレガシー認証をブロックするような条件付きアクセスポリシーを設定してあげると

実際のブロックはせず、ログに「[レポート専用]ではなく、[オン]にしていたらブロックしていたよ」という報告を挙げてくれます。
ただし、「ブロックしていたよ」という一覧だけを抽出して参照する、というのが難しいんですよね。なので、こういうときもLog Analyticsを使って見てみましょう。

Azure AD管理センターの[Workbooks]メニューから[条件付きアクセスに関する分析情報とレポート]レポートを開いて、事前に作成した条件付きアクセスポリシーでフィルターをかけます。すると、直近24時間で3つのFailureのイベントがあることがわかります。

さらにFailureをクリックすると、画面下部にはFailureとなったサインインイベントの詳細が確認できます。

以上の内容から2021年のレガシー認証廃止に向けて対処しなければならないイベント/ユーザーが確認できます。

iOSデバイスでレガシー認証をやめる

前回、iOSの標準メーラーでもレガシー認証になるという話を書いたら、こんなコメントをいただきました。

iOS12以降は標準メールクライアントもOAuth対応のはずだけど、再セットアップしないと基本認証のままになるかな？ https://t.co/PbUuZ0QTCo

— khak (@k_h_a_k) July 9, 2020

iOS12以降はOAuth対応なんだけど、前のバージョンのiOSのメールプロファイルをそのまま使っている場合、iOSが12になっただけではOAuthにならないのです。そのため、iOS12以上のバージョンになったならば、メールプロファイルは一度作り直しが必要になります。そうしないといつまでもレガシー認証を使い続けることになります。
なので、まずはみんなが使っているiPhoneのiOSバージョンを確認し、iOS12以上になっているなら地道にアナウンスしていく、サポートが対応していくなどを行っていきます。
前に登場したレガシー認証のクエリでUserAgentが表示されるように設定すると

ご覧のようにiPhone/iPadのバージョンと、iOSのバージョンが表示されます。
スラッシュのあとにある番号がiOSのバージョンで、1600以降がiOS12以上になります。

■ ■ ■

こんな感じで調査してひとつずつレガシー認証を潰していく。地道ですけど、この手の作業を重ねて、ある日突然ブロックされないようにしたいものですね。

【参考】Log Analyticsを使えない/使いたくない人はExcelでもJSON形式でエクスポートしたデータをもとに分析できるよ、という話
https://jpazureid.github.io/blog/azure-active-directory/new-tools-to-block-legacy-auth/

皆さんこんにちは。国井です。

今日はメールアドレスでAzure ADにサインインする話です。
メールアドレスでAzure ADにサインインするといえば、代替ログインIDが有名かと思います。

https://azuread.net/2016/07/19/aad-connect%e3%81%ab%e3%82%88%e3%82%8balternate-login-id%e8%a8%ad%e5%ae%9a/

Azure AD Connectは
オンプレミスADユーザーのUPNとAzure ADユーザーのUPNをマッピングする同期を行いますが、
代替ログインIDでは
オンプレミスADユーザーのmail属性とAzure ADユーザーのUPNをマッピングする同期を行います。(mail属性以外でも同期は可能)

これが一番大きな違いでした。
しかし、代替ログインIDを使うとハイブリッドAzure AD参加が利用できないなどの問題があり、あまりお勧めできる構成ではありません。
そこで、こうした問題を解決するために最近、Azure AD Connectで代替ログインIDを設定しないでメールアドレスによるサインインができるような機能がプレビューで登場しました。

今までの代替ログインIDとの違いは
代替ログインIDはオンプレミスADユーザーのmail属性とAzure ADユーザーのUPNをマッピングするのに対して、

メールアドレスでのサインインは、サインイン時のユーザー名にAzure ADのメールアドレスを使うので、Azure ADのメールアドレスさえ、ちゃんとしたアドレスになっていれば、
Azure AD Connectで同期されてくるUPNはどんな構成になっていてもいいのです。

■ ■ ■

実現の仕組みですが、とても簡単でAzure ADディレクトリでHomeRealmDiscoveryの設定を変えてあげるだけです。
HomeRealmDiscoveryとは、ざっくり言うとサインインを行うときに、どこのIdPでサインインするかを定義したものです。例えば、Azure ADではサインイン画面をつかさどるサーバー(下図のcommon部分)でユーザー名/パスワード(資格情報)の入力を受け付けると、UPNサフィックス(ドメイン名)部分を見て、その資格情報による認証を行うAzure ADディレクトリを決定します。

このとき、UPNサフィックス部分がレルム(Realm)、レルムの情報に基づいてどこのAzure ADディレクトリに行けばいいの？を見つけるプロセスがHomeRealmDiscoveryというわけです。(※ADFSとお友達の方には馴染みの深い機能ですよね)

このHomeRealmDiscoveryを設定変更し、UPNサフィックスではなく、メールアドレスのサフィックスを参照してHomeRealmDiscoveryプロセスを行いましょう
というのがメールアドレスでのAzure ADサインインの機能なのだと思います。

実際に設定してみる

Azure AD PowerShellのPreview版をインストールし、Connect-AzureADで接続したのち、
こちらのコマンドレットを実行します。

New-AzureADPolicy -Definition @('{"HomeRealmDiscoveryPolicy" :{"AlternateIdLogin":{"Enabled": true}}}') `
     -DisplayName "BasicAutoAccelerationPolicy" `
     -IsOrganizationDefault $true `
     -Type "HomeRealmDiscoveryPolicy"

完了したら、後はカスタムドメイン名として登録されたドメイン名を持つメールアドレスをActive Directoryで設定し、Azure ADへ同期します。
ここではtr930.adfs.jpというカスタムドメイン名をあらかじめ設定していますので、メールアドレスもご覧のように設定してみました。

そして、https://myapplications.microsoft.com/ にアクセスし、
サインイン画面で電子メールアドレスを入力してみると、

メールアドレスでサインインできました。

ツッコミどころ満載な検証をしてみる

この機能をマイクロソフトが提供すると聞いて、私が最初に思ったことはメールアドレスという必ずしも一意ではない名前をユーザー名として使って大丈夫なの？です。そこで、思いつきそうなパターンでサインインを試してみました。

proxyAddresses属性でサインインできる？

mail属性でなくてもOKでした。(ただしproxyAddresses属性を利用する場合はmail属性はカラにしておく必要があるようです)
ちなみにproxyAddresses属性で、SMTP:とsmtp:のメールアドレスを2つ入れた場合、どちらのメールアドレスでもサインインできます。

カスタムドメイン名の登録のないドメイン名を使う

これはダメでした。メールアドレスには明確にカスタムドメイン名が含まれている必要があります。

Azure ADユーザーのUPNとオンプレミスADユーザーのメールアドレスが同じ場合

言葉にするとわかりにくいけど、こういう構成です。

サインインの名前で競合が発生する場合、オンプレミスADのユーザーを優先します。
つまり、Azure ADに作られた同じ名前のユーザーはもう二度とサインインできなくなりました。(怖！というかソフトマッチ的な機能はないのか..)

Azure ADユーザーのUPNとオンプレミスADユーザーのメールアドレスが同じ場合(2)

前のパターンと一緒ですが、今度はAzure ADに直接作られたユーザーがOffice 365のライセンスを持っている場合です。

オンプレミスADユーザーが同期されることによって、Azure ADユーザーが使えなくなるというのなら、Office 365ライセンスが割り当てられたユーザーのメールアドレスは闇に消えるのか？と思って検証してみました。
結果は、オンプレミスADユーザーにAzure ADユーザーが持っている Office 365 ライセンスは移管され、マージされます。
つまり、Azure ADユーザーは使えなくなるけど、Office 365のライセンスはオンプレミスADユーザーのアカウントを通じて引き続き利用可能ということです。

メールアドレスが同じオンプレミスADユーザーを作成した場合

ふたりのADユーザーで同じメールアドレスにした場合、片方のユーザーだけAzure ADに同期され、残ったユーザーは同期エラーでAzure ADにユーザーが作られることはありませんでした。でも、どういう理屈なんだろ？
もう疲れてAzure AD Connectのログを見る気力もなかったので、これは改めて確認してみます。

皆さんこんにちは。国井です。

外出先からVPNなしでオンプレミスのWebアプリケーションに接続できるようにするリバースプロキシ機能であるAzure ADアプリケーションプロキシ。コロナ禍で世界的に利用者数が増えたといわれており、私のところでもご質問をいただく機会が多くなりました。
以前からあるテクノロジーなので、ネットを見てください！という言おうと思ったら、
あまりAzure ADアプリケーションプロキシを使ったときの認証周りの話がネットでお見掛けしなかったので「今さらかよ」と思う人もいるかもしれないですが、
Azure ADアプリケーションプロキシの認証について触れてみたいと思います。

Azure ADアプリケーションプロキシとは

オンプレミスにあるサーバー(Webアプリケーション)に外出先からアクセスできるようにする「リバースプロキシ」です。本当だったらオンプレミスのWebアプリケーションをOAuth2.0対応にして、クラウドに移行したいのですが、アプリケーションを改修する予算などない！という場合、外出先や自宅からオンプレミスのWebアプリケーションにアクセスする機会もあるでしょう。

従来であれば、会社にVPN接続してWebアプリケーションにアクセスするというやり方もあるのでしょうが、コロナ禍でVPNはどこの会社でもパンク状態。
そこでVPNを使わないでWebアプリケーションへの接続を実現するアプリケーションプロキシが注目されているのです。

アプリケーションプロキシの仕組み

アプリケーションプロキシはプロキシコネクタと呼ばれるツールが提供されていて、コネクタをインストールすると、インストールしたサーバー(下の図で言うとProxyコネクタ)がAzure ADとの間でセッションを確立し、クライアントからの接続待ち受けをします。
そして実際にクライアントからの接続要求があると、
Azure AD App Proxy → Azure AD → コネクタ → Webアプリケーション
(下の図で言うとWebサーバー)のルートでアクセスを実現します。
このとき、ポイントになるのはコネクタがAzure ADに接続していることです。
コネクタからAzure ADへの接続になるので、アウトバウンドTCP443の通信だけを行うため、ファイアウォールに特別な設定を行うことなく通信が実現できるというメリットがあります。(下の図は5年ぐらい前に書いたアプリケーションプロキシを利用した構成図です。)

Webアプリケーションへの接続時の認証・認可

まずAzure ADアプリケーションプロキシを利用するときの認証・認可は2つに分かれます。

・ひとつはAzure ADにアクセスするときの認証・認可
・もうひとつはWebアプリケーションにアクセスするときの認証・認可

このうち、Azure ADにアクセスするときの認証・認可はアプリケーションプロキシの設定でAzure ADの認証を済ませたユーザーだけがアプリケーションプロキシを利用できるようにするという設定があるので(これを事前認証と言います)、これを使います。ちなみに事前認証を行わず、URLさえ知っていれば誰でもアプリケーションプロキシを利用できるようにすることも可能です(つまり会社のWebアプリケーションを外部公開したいときに使う設定ですね)。

一方、Webアプリケーションにアクセスするときの認証・認可ですが、
このアクセスはデフォルトでは匿名アクセスになります。
だけど、社内Webアプリケーションに接続するのに、匿名アクセスってありますか？
普通は認証・認可を済ませたうえでWebアプリケーション(下の図で言うとWebサーバー)に
アクセスすると思うのです。

そこで、ここからはAzure ADの認証・認可とWebアプリケーションの認証・認可をまとめてしまい、シングルサインオンアクセスできるようにする方法を見ていきます。
(前置きが長くなりましたが、今日の議題はこれです)

Kerbeorsの制約付き委任

上の図にも書きましたが、Azure AD Connectを利用している会社の場合、Active Directoryのユーザーアカウントと同じ名前のAzure ADユーザーがいて、そのユーザーでクライアントからAzure ADにサインインしている場合があります。
この場合、Azure ADにサインインしたユーザーと同じ名前のユーザーがActive Directoryにいるわけですから、Active Directoryのユーザーとみなして社内リソースへのアクセスをさせたい。

しかし、これにはハードルがあります。
WebアプリケーションにアクセスするユーザーがActive Directoryのユーザーであることを証明するためにはActive Directoryドメインコントローラーから発行されるKerberosチケットを持っていることが前提となります。
ところがこのKerberosチケット、認証を行ったデバイスとWebアプリケーションにアクセスするデバイスが同一でなければ発行されません。

アプリケーションプロキシを経由してWebアプリケーションに接続するとき、プロキシコネクタがクライアントに代わって代理アクセスをするため、
認証を行ったデバイス ＝ クライアント
Webアプリケーションにアクセスするデバイス ＝ プロキシコネクタ
となり、同一デバイスではなくなってしまうからなんですね。

これを無条件で認めたら、他人のチケットを盗んで不正アクセスに及ぶ可能性があるのです。

サインインするデバイスとチケットの発行先デバイスは別々だけど、チケットを発行してあげたい。そこで登場する救世主こそがKerberosの制約付き委任 (Kerberos Constrained Delegation)、通常KCDと呼ばれる機能です。
KCDは認証を行ったデバイスとWebアプリケーションにアクセスするデバイスが同一でなくてもアクセスを認めますよ、という例外を認める機能で、
これを利用すれば、Azure ADにサインインしたクライアントコンピューターとは別のコンピューターであるプロキシコネクタに対してKerberosチケットを発行し、プロキシコネクタがWebアプリケーションにアクセスすることを認めるようになります。

アプリケーションプロキシ × KCD

Windows ServerでWebサーバーとしてIISが動いていて、下の画面のようにWindows認証が有効になっているとWebページにアクセスするときにKerberosチケットを持っていないとアクセスできなくなります。このような設定にしている前提でここからは話を進めます。

まず、KCDの設定はActive Directoryユーザーとコンピューターを開き、コンピューターアカウントのプロパティを開いて行います。
ここではMSC0569G-DC0というコンピューターがコネクタ、
MSC0569G-SV0というコンピューターがWebアプリケーションが実装されたサーバー
としてみてください。

コネクタとなるコンピューターアカウントのプロパティを開き、[委任]タブから[指定されたサービスへの委任でのみこのコンピューターを信頼する]を選択して、Webアプリケーションが実装されたサーバーのhttpサービスを追加します。
これでActive Directory側のKCDの設定は終わり。
ちなみに「Webアプリケーションが実装されたサーバーのhttpサービス」という指定は内部的に http/サーバー名 という記述方式を取ります。
(これをサービスプリンシパルなどと呼ぶわけですが、これ以上話をややこしくしたくないので、今日はその話はなしで。)

続いてAzure AD側でKCDを利用する場合、アプリケーションプロキシの設定画面からシングルサインオンを選択し、

シングルサインオン画面で、[Windows統合認証]を選択します。

そして、内部アプリケーションSPN項目に「http/サーバー名」の記述方式で、アクセス先となるWebアプリケーションのサーバー名を記述します。

KCDに関連する設定はこれで終わり。
では実際にアクセスしてみましょう。
テストとして、IISではc:\inetpub\wwwrootにindex.aspxファイルを作成し、
以下のような内容をメモ帳で書き込みました。

<%@ Page Language="C#" %>
<html>
<head><title>Sample Web Page</title></head>
<body>
<form id="form1" runat="server">
<h1>DNS hostname: <%=System.Net.Dns.GetHostName()%></h1>
<h1>Request host: <%=Request.UserHostName%></h1>
<h1>Request user: <%=Request.LogonUserIdentity.Name%></h1>
<p>Request Time: <%=DateTime.Now.ToString() %></p>
</form>
</body>
</html>

作成できたら、クライアントからアクセスパネルにアクセスし、
Azure AD Connectで同期されたユーザーでサインインします。
そして、アプリケーションプロキシで公開されたWebアプリケーションにアクセスすると、
ご覧のようなページが表示されました。ユーザー名にcontoso0\sekineと表示されていますが、これがActive Directoryユーザーの名前になります。

みんなWindows統合認証使ってる？

ここまでIISでWindows統合認証を使っている前提でシングルサインオンする方法を紹介しましたが、そもそも社内のWebアプリケーションでWindows統合認証を使ってますでしょうか？
Active Directoryと連動することを意識して作られたWebサーバーであれば当然利用しているでしょうが、世の中、そんなWebサーバーばかりではありません。
MySQLにユーザー名とパスワードを保存したフォームベースの認証を実装したWebアプリケーションもあるでしょう。そんなダサいWebアプリケーションなど今すぐ捨ててしまいたいと思うでしょうが、予算の都合でそれができないのもまた事実。

そんな場合にはAzure ADにアプリケーションプロキシを登録するときにシングルサインオン設定で[パスワードベース]を利用するのも一つの方法です。[パスワードベース]を利用すればフォームベースの認証画面に自動的にユーザー名とパスワードを入力してくれるので、シングルサインオンっぽいものを実現できるようになるでしょう。
この設定にはAzure AD Premium P1が必要になりますが、検討の余地はあると思います。

■ ■ ■

ここまでアプリケーションプロキシの機能についてシングルサインオン機能を中心に見てきました。そのため、アプリケーションプロキシそのものの設定方法については省略してしまいました。その点についてはMSさんのサイトや他の方のブログなどで補足していただければと思います。

■参考文献
KCDの概要
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-single-sign-on-with-kcd

アプリケーションプロキシの手順だけ、さくっと知りたいときにお勧め
https://qiita.com/Aida1971/items/ae42d1ae371794f12780

トラブルシューティングTips
https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/application-proxy-back-end-kerberos-constrained-delegation-how-to