Quantcast
Channel: Always on the clock
Viewing all 439 articles
Browse latest View live

SCCM評価ガイド クラウド管理ゲートウェイ編登場

$
0
0

皆さんこんにちは。国井です。
今日は連投です。

一部の方には少しお話ししていましたが、SCCM評価ガイドのクラウド管理ゲートウェイ編がマイクロソフトさんからリリースされました!

マイクロソフトのエンタープライズ モビリティでは、ユーザー認証、デバイス、アプリ、データといった 4 つのレイヤーを適切に管理、保護することができます。
Enterprise Mobility + Security - マイクロソフト クラウド プラットフォーム - Microsoft Cloud-Platform - JA (日本語)

[System Center Configuration Manager (CB) 評価ガイド クラウド管理ゲートウェイ編]のリンクをクリックしてダウンロードしてください。

SCCMは本来、オンプレミスに設置されたクライアントを管理することを目的に作られた製品ですが、最近では社外でクライアントを利用することも増えてきました。こうしたクライアントをオンプレミスにあるSCCMサーバーからどうやって管理するか?というのが長年の課題になっていました。

クラウド管理ゲートウェイ(CMG)は、SCCMのサイトシステムの役割をリバースプロキシ経由で外部公開するもので、

image

外出先のコンピューターはMicrosoft Azure 上に展開されたゲートウェイサービスに接続するだけで、あとはゲートウェイサービスが社内にあるサイトシステムに代理接続してくれるというものです。今までのSCCMでは、サイトシステムをHTTPSベースで構築し、DMZにサーバーを公開して、、ということが必要でしたが、CMGであればHTTPSベースの構築が不要になります。

経験のある方であれば、HTTPSベースのサイトシステム構築って、めちゃくちゃ面倒だったことがわかると思うので、HTTPSベースの構築が要らないCMGは革命的なテクノロジーなのです(大げさ?)。

評価ガイドはSCCM 1806ベースで作成しているので、直近のバージョンでは多少手順が異なりますが、参考になれば幸いです。


【101シリーズ】Azure ADユーザーの無効化と削除

$
0
0

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

Azure ADって最近、機能が増えすぎて基本的なところを確認する機会が失われているように思います。なので、今日は基本に戻ってAzure AD Connectから同期されたユーザーの無効化機能について色々なパターンを考えてみたいと思います。

Azure ADユーザーの無効化

Active Directoryではアカウントの無効化って明確な設定がありますが、Azure ADには有効/無効という設定項目がありません。そのため、[サインインのブロック]が有効/無効の設定の代わりを果たしています。

image

Azure AD Connectで同期された無効なユーザー

次に、Azure AD Connectを使って無効なActive Directoryユーザーを同期すると、[サインインのブロック]欄が[はい]になった状態のユーザーが出来上がります。[サインインのブロック]欄は[いいえ]にすることもできますが、オンプレミスの設定が優先されるので、次回同期時に[サインインのブロック]設定は[はい]に戻ります。

Azure AD Connectで同期される無効扱いのユーザー

その他、Active Directoryで[アカウントを無効にする]を設定する以外にも、ユーザーを利用できなくする設定は色々あります。これらの設定を行ったのち、Azure AD Connectでユーザーを同期するとAzure ADのユーザーにはその設定が反映されるのか調べてみました。結果は以下の通りです。

ADの設定 Azure ADユーザーは無効化されるか?
アカウントの無効化 はい
ロックアウト いいえ
ログオン時間 いいえ
ログオン先 いいえ
パスワードの有効期限切れ いいえ

あらら、アカウントは無効にしない限りAzure ADのユーザーが無効になることはないのですね。

削除したユーザー

Azure ADに作られたユーザーを削除した場合、Azure ADのゴミ箱である[削除済みのユーザー]に格納します。

image

画面にも書いてある通り、削除してから30日以内であれば復元できるので、「あ、やっちまった」ってときは[削除済みのユーザー]からユーザーを選んで[ユーザーの復元]をクリックして復元しましょう。そうすれば、パスワードも含めてちゃんと復元してくれます。

同期したユーザーの削除

Azure AD Connectで同期したユーザーをActive Directory側から削除した場合、Azure ADに同期されたユーザーも削除されます。
そして、削除されたユーザーはAzure ADに直接作成したユーザーと同じく[削除済みユーザー]に格納されます。
ここからが興味深いのですが、[削除済みユーザー]を復元すると、Azure AD Connectと同期されたユーザーとしてではなく、Azure ADに直接作成したユーザーとして復元されます
少し詳しく動きを説明します。

image

上の図では、user1とuser2という2つのユーザーがあります。2つのユーザーはもともとActive Directoryに作成したユーザーをAzure AD Connectで同期したものですが、user2だけはActive Directoryから削除し、その後、同期を行いました。

すると、user2は一度削除されます。削除されたユーザーは先ほどの説明の通り[削除済みのユーザー]に格納されます。(この時点でソースが[Azure Active Directory]になっているのはなぜ??)

image

そして、ユーザーを復元すると、Azure  ADのユーザーとして復元されます。

image

これにより、user2はActive Directoryからは完全に切り離されたAzure ADのユーザーとなるので、属性情報も自由に設定できるようになります。

Azure ADユーザーの属性情報一覧

$
0
0

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

今日はAzure ADユーザーで利用可能な属性の話です。
Azure ADでグループを作成するときに[動的ユーザー]という設定を利用すれば、ユーザーの属性に基づいてグループのメンバーを構成できます。
しかし、この機能、設定するときに属性の名前が英語で書いてあって、Azure管理ポータル画面に表示されている名前と異なるんですよね..
↓これが属性に基づいてグループのメンバーを設定している画面。「department属性が営業だったらメンバーとする」という設定なんだけど、department属性ってなに?

image

↓これがユーザーのプロパティを開いたときの画面。属性名は日本語なんですけど。

image

動的ユーザーのグループを作るときにユーザー属性の日本語<=>英語のマッピング表があったらいいなと思い、作ってみました。

image

image

それでもって、一覧にしたものがこちら(*は動的ユーザーで使えない属性)

属性名 表示上の名前
userPrincipalName ユーザー名
DisplayName 名前
GivenName
surName
userType ユーザータイプ
ObjectID オブジェクトID
dirsyncEnabled ソース
jobTitle 役職
department 部署
管理者*
BlockCredential サインインのブロック*
UsageLocation 利用場所
StreetAddress 番地
State 都道府県
Country 国/リージョン
PhysicalDeliveryOfficeName 会社
City 市区町村
PostalCode 郵便番号
telephoneNumber 会社電話
Mobile 携帯電話
年齢グループ*
未成年および同意*
ライセンス*

GUIの画面で見えているもの以外にも属性はあるのですが、Azure AD PowerShellを使うことによって見える属性、設定できる属性があるので、ご興味があれば使ってみてください(具体的な設定は別の機会に)。

このコースでは、Office 365 をはじめとするクラウドサービスのユーザー認証の設計と実装について学習します。
Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編) | 株式会... - 株式会社イルミネート・ジャパン

Azure AD参加したデバイスでのAzure ADユーザーサインインについて

$
0
0

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

オンプレミスからクラウドへ、という流れはサーバーだけでなく、クライアントデバイスにも起きていると思います。今までであれば、Active Directoryドメインにデバイスを参加させて、、という方法でしたが、徐々にAzure ADにデバイスを参加させて、クラウド経由でデバイス管理という方向に進んでいると思います。

そんなことを計画すると出てくるのは、Azure AD参加のデバイスの扱いについてです。
最近、ご質問をいただくことが多いので、少しまとめておきます。
え、Azure AD参加とは何かって?それはこちらで確認してください。

Azure AD参加時のユーザーアカウント

例えば、yamada@adfs.jp というユーザーでAzure AD参加を行った場合、Azure ADユーザーでWindowsサインインができるようになります。ただし、Windowsローカルにそのユーザーが作られることはありません。Azure AD参加のユーザーはワークグループのユーザーじゃないから当然ですよね。

1

そこでコマンドプロンプトで「whoami /all」コマンドを実行してみます。すると、ユーザーの情報がazuread\yamadaのように表示され、AzureADドメインのyamadaユーザーと認識されていることがわかります。
しかし、Azure AD Connectから同期されたユーザーの場合、ユーザーの情報がcontoso00\yamadaのようにオンプレミスドメインのユーザーとして表示されるのです。

2

しかし、SIDは本物のADドメインのYamadaユーザーとは違う、、なんでやねん。

Azure ADユーザーに与えられる権限

Azure AD参加を行うときに使用したAzure ADユーザーでサインインすると、そのユーザーはAdministratorsグループの権限、そのほかのAzure ADユーザーでサインインすると、Usersグループの権限が割り当てられます。
事実、[コンピューターの管理]管理ツールでAdministratorsグループのメンバーを見てみると、Yamadaユーザーが含まれていることがわかります。

3

じゃあ、Windows 10で最初に作られたユーザー(以下のケースではadminユーザー)と同等の権限をユーザーが持つのか?と言われると、それもまた違います。以下の画面はadminユーザーでwhoamiコマンドを実行した様子です。whoamiコマンドの実行結果では上記のyamadaユーザーとは異なる権限を保有していることがわかります。

4

実はこのことが理由で、Azure AD参加しているデバイスに管理者権限が必要なアプリをインストールしようとすると失敗するケースがあります。どうして失敗しているかによって対処方法は異なりますが、Azure ADユーザーから一度サインアウトして、adminユーザーでサインインしなおしてアプリをインストールする、という操作が必要になる場合も最悪ありますので、この点は注意が必要です。

Azure ADユーザーに対するファイル共有のアクセス許可割り当て

Azure ADユーザーはワークグループのユーザーでもないし、ADドメインユーザーでもない。この場合、ファイル共有を作ってアクセス許可を割り当てようとしてもGUI画面からユーザーを選択できません。そのため、PowerShellのGrant-SmbShareAccessコマンドレットを使ってアクセス許可を割り当てる必要があります。詳しい方法はこちら(英語)で紹介していますので、参考にしてください。

このコースでは、Office 365 をはじめとするクラウドサービスのユーザー認証の設計と実装について学習します。
Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編) | 株式会... - 株式会社イルミネート・ジャパン

Windows AutopilotからAzure AD参加したデバイスでのサインインについて

$
0
0

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

少し間が空いてしまいましたが、前回紹介したAzure AD参加したデバイスでサインインした時に、どのような権限を持つか?という話の続きです。
前回は普通にWindows 10のコンピューターでAzure AD参加した場合を見てみましたが、Windows AutopilotからAzure AD参加だと少し動きが変わります。そのあたりを今日は紹介します。

まず、Autopilotからデバイスをセットアップした場合、クラウドアカウントしかいませんので、ご覧のようにユーザー一覧をみるとローカルアカウントはひとつもありません(厳密に言うとローカルアカウントはあるけど、すべて無効化されている状態です)。

1 (002)

そして、これが今回の話の結論なのですが、Autopilotからセットアップした場合、Azure ADのグローバル管理者がWindowsの管理者権限を持ち、Autopilotでサインインしたユーザーは一般ユーザーとして扱われることになります。

実際にAutopilotでサインインしたユーザーでPowerShellを起動し、whoami /allコマンドを実行した様子がこちら。

7 (002)

これに対して、Azure ADのグローバル管理者でサインインして、whoami /allコマンドを実行した結果がこちら。

4 (002)

明らかに違いますよね。
参考までにローカルのAdministratorsグループのメンバーを開いて見てみると、

2 (002)

SIDだけが書かれたユーザーが入っていることがわかります。しかし、このSID、先に出てきた2人のユーザーのSIDとも違うんですよね。(じゃあ、あんたは誰なのよ??)

リモートデスクトップでサインインできない問題

リモートデスクトップでサインインするときによく起こる問題のひとつにRemote Desktop Usersグループじゃないからサインインできない、というのがあります。

6

Remote Desktop Usersグループのメンバーにユーザーを入れればいいんでしょ?と思うかもしれないけど、これが結構面倒なのです。
まず、Azure ADユーザーはローカルユーザーじゃないからRemote Desktop Usersグループのメンバーにユーザーを入れようとしてもできない!
結局、EveryoneグループをRemote Desktop Usersグループのメンバーに入れちゃいました (なんかいい方法ないっすかね..)
また、Windows 10コンピューターからsysdm.cplコマンドを実行し、[リモート]タブから[ネットワークレベル認証でリモートデスクトップを実行しているコンピューターからのみ接続を許可する]のチェックを外しておきます。

5 (002)

それから、RDPファイルに文字列を入れて細工しておきます。詳しくは以下のサイトを参考になさってください。
https://www.cloudou.net/azure-active-directory/aad007/

ここまでの設定が完了したら、RDPファイルをダブルクリックしてでサインインします。
ユーザー名は上記サイトにもあるように、azuread\ユーザー名@ドメイン名 でサインインすればリモートデスクトップ接続できるようになります。

Autopilotで展開したデバイスのワイプに関わる問題

最後に、Autopilotで展開したデバイスをIntuneからセレクティブワイプ(リタイヤ)した場合について。Azure AD参加しているデバイスをリタイヤすると、Azure AD参加の状態も削除されます。つまりAzure ADのユーザーではサインインできなくなるってことです。前にもお話しした通り、Autopilotで展開したデバイスはローカルにユーザーを作らないので、リタイヤするとWindowsにサインインできるユーザーはいなくなります。
つまり、二度とWindowsにサインインできなくなるのです。

このコースでは、Office 365 をはじめとするクラウドサービスのユーザー認証の設計と実装について学習します。
Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編) | 株式会... - 株式会社イルミネート・ジャパン

非アクティブなIntuneデバイスの削除について

$
0
0

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

先日、お客さんとのお話の中でIntuneに登録されたデバイスが勝手に消えていく、というお話を伺いました。これはIntuneに用意されているデバイスの「クリーンアップルール」と呼ばれる設定が原因で起こる問題です。
クリーンアップルールとは、Intuneに登録されたデバイスが一定期間インターネット接続を行っていないと勝手にIntuneのデバイス一覧から削除していしまうもので、デフォルトでは最後にIntuneとデバイスの間で通信(チェックアウト)を行ってから270日後に削除するように設定されています。

ちなみにクリーンアップルール設定はMicrosoft 365デバイス管理センター サイトから[デバイス]-[デバイスのクリーンアップルール]から、その設定を変更できます。
キャプチャ (002)

ただ、270日より長くしたり、設定自体を無効にしたりすることはできないんですよね..

ですので、削除されないようにすることよりも、いつ削除される予定なのか?という状況を把握することに徹するしかない、というのが私の考えです。
(これよりも、もっといいアイデアがあったら教えていただけるとうれしいです)

削除される予定のデバイスの把握方法 – その1

[デバイスのクリーンアップルール]で削除までの日数を変更すると(保存ボタンは押さなくてよい)、[問題のデバイスを表示します]リンクから消される予感のあるデバイスが表示されます。
私のテナントで削除までの日数を30日にしてみたら、、

image

ご覧のように3台のデバイスが削除されるよ、と予言をしてくれました。

削除される予定のデバイスの把握方法 – その2

IntuneのPowerShellからGet-IntuneManagedDeviceコマンドレットを使えば、Intuneに登録されているデバイスの一覧を見るだけでなく、最後にチェックインした日時も同時に確認できます。

image

Get-IntuneManagedDeviceコマンドレットでは、デバイスを利用するユーザーも同時に表示されるので、誰が使う、どのデバイスがそろそろ削除される!というのが把握できます。

Get-IntuneManagedDeviceコマンドレットを定期的に実行して、前回実行した時と今回実行した時で結果が異なれば、削除されたデバイスがいたってことになるので、そこを抽出してアラートを投げるようなスクリプトを書こうとしたのですが、結構大変だったので時間ができたときに改めて作ってみたいと思います。

Microsoft Authenticatorアプリを複数デバイスで利用

$
0
0

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

Azure ADで多要素認証を利用する場合、携帯電話による通話やSMSによるワンタイムパスワードなど、いくつかの認証方法が選択できますが、その中のひとつにMicrosoft Authenticatorを利用した方法があります。Microsoft AuthenticatorはiOS, Android用アプリで、初期設定でアカウントとアプリを紐付けておくと、多要素認証に利用することができます。
ところが、このAuthenticatorアプリ、今まで1アカウントにつき、1台のデバイスにインストールされたAuthenticatorアプリしか使えないという制約がありました。そのため、携帯を家に置いてきてしまったらどうするのか?とか、機種変更のときはどうするのか?とか、いろいろあったわけです。
それがいつの間にか、その制約がなくなり、複数のデバイスにインストールして利用できるようになりました(ということをお客さんに指摘されて初めて知りました)。
では、初期設定から見てみましょう。
まずは多要素認証が有効になっているユーザーでアクセスパネル(https://myapps.microsoft.com/)にアクセスし、[プロファイル]をクリックして、

image

[追加のセキュリティ確認]をクリックします。ここをクリックすると、多要素認証で使う認証方法を選択する画面に移動できます。

image

[認証アプリまたはトークン]にチェックをつけて、[Authenticatorアプリの設定]をクリックして、

image

QRコードが表示されたら、登録するデバイスのAuthenticatorアプリを起動し、QRコードを読み取ってください。

image

これで携帯電話(というかAuthenticatorアプリ)の登録は完了です。簡単でしょ?

image

同じ要領で2台目も登録します。

image

これで出来上がり。あとは実際に多要素認証が有効になっているユーザーでサインインすれば、自動的にAuthenticatorアプリから通知が出てくるので、[承認]を押すだけです。

image

このときに面倒になるのが、2台のデバイスを登録すると、[サインインを承認しますか?]の通知が2台同時に出てくることです。どちらのデバイスからでも多要素認証に応答できて便利なんだけど、一方で鬱陶しい。
そういう時はQRコード読み取りの画面で、[通知をオフにしてアプリを構成]をクリックしてからQRコードの読み取りを行います。そうすると、上の通知画面は出てこなくなります。

image

通知が出てこなくなったら多要素認証できなくなるんじゃないか?って思った人もいると思うのですが、1台でも[通知をオフにしてアプリを構成]から登録すると、Authenticatorアプリの通知機能は使わなく(使えなく?)なり、代わりにAuthenticatorアプリに表示されるワンタイムパスワードを入力するような認証方式に切り替わります。

image

上の画面が出てきたら、Authenticatorアプリに表示される6桁の数字を代わりに入れることで多要素認証のサインインを完了できます。

IMG_0009

2台の携帯にAuthenticatorアプリを入れるとワンタイムパスワードの6桁の数字はそれぞれ違う数字になりますが、どちらの数字を入れてもサインインは成功します。

このコースでは、Office 365 をはじめとするクラウドサービスのユーザー認証の設計と実装について学習します。
Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編) | 株式会... - 株式会社イルミネート・ジャパン

Azure MonitorでAzure ADを監視

$
0
0

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

最近、Azure ADのトレーニングの中でログについてご質問をいただくことが多くなってきました。
Azure ADのログはPremiumの契約を結ばないと見られないことや、Premiumの契約があったとしても30日までしか保存されないなど、いろいろ課題があったりします。そこで、マイクロソフトでは次の方法でログのエクスポートをサポートしています。

1.CSVファイルにエクスポートしてローカル?に保存
2.Azure Storageにエクスポートして保存
3.Azure Monitorにエクスポートして参照できるように設定
4.Azure Sentinelにエクスポートして参照できるように設定

この4つのうち、2から4についてはMicrosoft Azureのテナント契約が必要になるので、クラウド上で完結するようにログを残しておきたい、有効活用したいということになれば、おのずとAzureテナントが必要になります。
ただ、Azureは従量課金制で基本料金がない上に、今回使うAzure Monitorの場合は、うちの会社のケースで言うと、ひとり当たり月1円程度のコストなので、取るに足らないものだと思っています。

話をもとに戻しますが、Azureのサービスを利用する2から4のうち、2は保存したデータを参照しずらい、4は(執筆時点では)まだプレビューなので価格がわからない、ということなので、ここでは3のAzure Monitorを使った方法を紹介します。

Azure ADとAzure Monitorの連携

Azure管理ポータル画面のAzure ADから[サインイン]ログを開いて[データ設定のエクスポート]をクリックします。診断設定画面が表示されたら、[診断設定を追加する]をクリックしてAzureとの連携を行います。

image

このとき、注意したいことが2つ。
Azure ADとAzureの連携設定は、Azure ADディレクトリのユーザー全員がPremiumユーザーであること、そしてAzureのテナントはAzure ADユーザーによって取得されたテナントを持っていることが前提になります。
もし、この時点でAzureテナントを持っていない場合は、画面にAzureテナントの取得を促す画面が出てくるので、その指示に従って取得しておいてください。

以上の条件をクリアしていると、こんな感じでAzureとの連携設定画面が登場します。

image

このとき、
[ストレージアカウントへのアーカイブ]を選択すれば、Azure Storageへのエクスポート
[イベントハブへのストリーム]を選択すれば、Azure Sentinelへのエクスポート
[Log Analytics]を選択すれば、Azure Monitorへのエクスポート
になります。
これらは排他的なものではないので、複数のサービスを同時に使うことも可能です。
また、画面下のところでは、AuditLogsとSigninLogsがありますが、サインインのログを収集する場合であればSigninLogsにチェックをつけておいてください。

では今回は、[Log Analytics]と[SigninLogs]にチェックをつけて先へ進めます。
と、言いたいのですが、Log Analyticsを利用する場合、Log Analyticsワークスペースを先に作成しておく必要があります。
Azure管理ポータル画面で、事前にLog Analyticsワークスペースを作成しておいてください。
image

[保存]をクリックすれば、設定は出来上がりです。しばらくすると、Azure Monitorにログがエクスポートされ、クエリを実行できるようになります。

Azure MonitorでのAzure ADログへのクエリ

ここからはAzure Monitorのブレードにアクセスして操作します。
前に作成しtらLog Analyticsワークスペースにアクセスし、ブレードから[ログ]をクリックします。
すると、Microsoft Defender ATPでもお世話になったクエリ画面が出てきます。

image

条件を設定せずに、すべてのログを参照したいときは「search *」と書いて実行してください。

【クエリ例】7日以内のサインインログを表示

サインインログを指定した検索は1行目にSigninLogsと書き、2行目以降にwhereなどの条件を入力します。

SigninLogs
| where CreatedDateTime >= ago(7d)

 

image

【クエリ例】特定のアプリにアクセスしたログを表示

アプリへのアクセスはAppDisplayNameで指定します。ちなみに、AppDisplayName以外に利用可能な項目(スキーマ)は画面左側のSigninLogsを展開すれば確認できます。

SigninLogs
| where AppDisplayName == "Office 365 Exchange Online"

 

image

【クエリ例】アクセスしたアプリを回数順に表示

summarize句を使えば、アプリの名前をアクセス回数にして集約できます。それをsort by句で降順表示します。

SigninLogs
| summarize signInCount = count() by AppDisplayName
| sort by signInCount desc

 

image

ちなみに最終行に「| render barchart」の文字列を追加すれば棒グラフにできます。

image

今回は省略しますが、ログ画面の右上にある[新しいアラートルール]をクリックすると、
あらかじめ指定したクエリに合致するログが生成されると、自動的に管理者にメールを送るなどのアラート設定もできるようになっています。

ここまで簡単にログに対するクエリの実行方法を紹介しましたが、こんなクエリが欲しいなどのご意見があれば一緒に考えてみたいと思っています。

このコースでは、Office 365 をはじめとするクラウドサービスのユーザー認証の設計と実装について学習します。
Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編) | 株式会... - 株式会社イルミネート・ジャパン

Intuneの同期を今すぐ実行する

$
0
0

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

今日は簡単なTipsです。
Windows 10 コンピューターがMicrosoft Intuneに登録されている場合、定期的にコンピューターはIntuneと通信(同期)して新しいポリシー設定やアプリの設定などを受信します。ところが、しばらく通信が行われていなかったり、検証環境だったりすると、「今すぐ同期してくれ!」ってとき、あると思います。

本来であれば、Windows 10コンピューターの[設定]アプリから[同期]のボタンをクリックして同期しますが、

image

これをコマンドで実行したい。そんなときは deviceenroller.exe を使います。

deviceenroller.exe ファイルは c:\windows\system32 フォルダーに入っているツールで、実は[同期]ボタンをクリックしたときにも同じコマンドが実行されています。
タスクスケジューラの[Microsoft]-[Windows]-[EnterpriseMgmt]からID番号の入ったフォルダーを開くと、Schdule #1で始まるタスクが登録されており、

image

この中にdeviceenroller.exeコマンドが入っていることがわかります。
実行するときは

c:\windows\system32\deviceenroller.exe /o “ID番号” /c

のように入力します。

ID ってどうやって調べる?

deviceenroller.exe を実行するときのID番号ですが、Enrollment IDといって、Intuneにデバイスを登録することで生成されるIDです。
ところがこのID、クラウド側ではだれに何番が割り当てられているのか、わからないんですよね…

自分のコンピューターのID番号だったら、タスクスケジューラから調べればいいんだけど、他のコンピューターのIDとなると… 残念ながらわかりません(簡単な方法があったら、どなたか教えてください!)。
ということで、私はMicrosoft Defender ATP(MDATP)を使ってみました。

MDATPのポータルサイトにアクセスし、特定のコンピューターを選んで、タイムラインを表示させたうえで、deviceenroller.exeで検索すると、過去にdeviceenroller.exeを実行した履歴がわかります。

image

もっと良いやり方あると思うんですけどね..
いずれにしても調べた結果に基づいて、コンピューターでコマンドを実行すると、同期が勝手に始まります。

ちなみに結果についてはイベントビューアの[アプリケーションとサービス ログ]-[Microsoft]-[Windows]-[DeviceManagement-Enterprise-Diagnostics-Provider]より確認できます。

Office 365とクラウドサービスの認証ベストプラクティスコース最新日程

$
0
0

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

ご好評いただいている「Office 365とクラウドサービスの認証ベストプラクティス」コースですが、2019年10月までの日程に続いて、2019年12月と2020年2月にそれぞれ追加開催することになりました。

12月23日~25日
2月25日~27日

12月23日って、そんなタイミングかよ!そもそも祝日じゃないの?と突っ込まれそうですが、12月23日は今年から平日なんですよね。加えて、ベンダーさんだとお客様先に伺うことのないタイミングでトレーニングを受けたいというご要望をいただくことが多く、あえてこの日程を設定してみました。
(実際、2018年も12月最後の土日はお客様先でトレーニングを開催していました)

これまでの開催について

これまで8月と10月に2度開催したのですが、お客様に満足していただけた声をいただくだけでなく、参加したお客様どうしでコミュニケーションをされていたことが印象的でした。
うちの会社だとこんなことで困っているとか、
うちの会社でこの機能を使ったときにはこんなことが起こったとか、
こうした話が多く飛びかい、参加された方は色々な方面から情報が得られたことを喜んでいらっしゃる様子でした。また、参加される方も多くないので、気兼ねなく、なんでもお話しできることも特徴なのかもしれません。

Azure ADをこれから導入する方、案件で抱える方、お悩みの方など、色々な方のご要望を満たせるように尽力しますので、ぜひご検討ください。
コースの詳細情報は以下のリンクからご覧いただけます。

このコースでは、Office 365 をはじめとするクラウドサービスのユーザー認証の設計と実装について学習します。
Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編) | 株式会... - 株式会社イルミネート・ジャパン

Azure ADとは?を最初から考えてみる

$
0
0

皆さんこんにちは。国井です。
Azure ADのビジネスに携わって数年が経ちますが、あれこれ新しい機能ばかりがクローズアップされて、基本的な概念などをざっくり知る機会が失われつつあるように思います。ということで、改めてAzure ADとは?を知りたい人のために紹介してみたいと思います。

■ ■ ■

私がまだ大学生だったころ、友人のアンドリューとともによくスキーを楽しんでいました。
(ADFSとは?フェデレーションとは?を知る方法でも登場した、あの彼です)
今ほど外国籍の人(特にアングロサクソン系の人)を日本で見かけることが多くない時代ということもあって、アンドリューはひときわ目立つし、どこへ行っても一度で覚えられる存在でした。そのため、スキー場なら、どこに行っても「顔パス」でリフト乗り場のゲートを突破できたのでした。
(スキー場などのサービスにアクセスするための許可証のことをID管理の世界では「トークン」と言いますが、アンドリューにとってのスキー場のリフトに乗るためのトークンは「顔パス」ということになります)

Free-Photos / Pixabay

ある日、私とアンドリューは日帰り温泉に行こうという話になり、スキー場から近くの温泉に向かいました。20:55に温泉に到着したものの、看板を見ると温泉の営業時間は21:00まで!
今日は諦めようと促す私に対して、アンドリューは「ガイジンだから大丈夫」などと言い出して、温泉の番頭さんに交渉し、21:00を過ぎているのに温泉に入れてもらえました。
その日を境に、レストランに一緒に行けば「ガイジンだからこのメニューは食べられない」と言ってメニューにない料理を作らせるなど、やりたい放題。
アンドリューにしてみれば「ガイジンだから」のキーワードを使えばなんでもできると考えたのでしょう。「ガイジンだから」トークンを手にして、あらゆるサービスへのアクセス権を得ていたような状態です。

そんなアンドリューにも「ガイジンだから」トークンが通用しない場所がありました。
それは日本の入国審査です。
あとで知ったのですが、彼にはオーバーステイの履歴があったのです。

■ ■ ■

トークンは一度持てば、どこでもアクセスできるわけではなく、通用する世界と通用しない世界があります。

Active Directoryの場合であれば、会社の中に作られた「ドメイン」という範囲がトークン(Active Directoryの場合はチケットと呼びます)が通用する世界になります。
ですので、Active DirectoryにIDとパスワードを入力して、もらえるトークンでアクセスできるのはドメイン参加しているサーバーだけになります。ですので、Active Directoryを持っている会社でもクラウドサービスにアクセスすることになったら、改めてIDとパスワードを入れなければならないのです(Active Directoryで作ってもらったトークンはクラウドで使えないですからね)。

 

これに対して、Azure ADで発行するトークンはクラウドで有効なトークンを発行します。そのため、Azure ADにIDとパスワードを入力してサインインしたユーザーは、追加でIDとパスワードを入力しなくても様々なクラウドサービスにアクセスできるようになるのです。

こうやって見ると、Active DirectoryとAzure ADの違いって、トークンが利用できる範囲がドメインなのか?クラウドなのか?という違いなだけで、トークンを発行して、どこかにアクセスできるようにして.. という動きはまったく変わらないのです。

では、最後によくある質問にまとめて回答してみましょう。

Azure ADはどうやってインストールするの?

クラウドから提供されるサービスなのでインストールとか、必要ありません。
一般的には Office 365 を契約することによって自動的に作成されちゃったというケースが多く、作成されちゃったものをそのまま利用することが多いです。

なんでActive DirectoryをインストールしないのにAzure Active Directoryっていうの?

それは作った人に聞いてくださいw
私なりに頑張って解釈すると、Active Directoryのように「トークン」を使ってアクセス権管理するサービスをAzureのクラウドサービスとして提供しているからだと思います。

Azure ADはどこにあるの?

マイクロソフトのデータセンターにあります。ユーザーなどを作った場合、その情報は他のデータセンターに複製して冗長化しているので、日本でユーザーを作っても国内にデータが留まるわけではないです。

Microsoft Azureを契約していないのにAzure ADってどういうこと?

先ほど、Office 365を契約すると作られちゃうって言いましたが、これってAzure関係ないですよね。これがAzureとAzure ADの関係性をややこしくしているところなのです。
今日は簡単に、わかりやすく、というモットーで書いているので、簡単に回答するなら、Azure ADに「Azure」という言葉が付く理由を考えるのはもうやめましょう。

Azure ADからどんなクラウドサービスにもアクセスできる?

Azure ADで発行されたトークンをもとにアクセスできるクラウドサービスは事前にAzure ADに登録しなければなりません。登録できるクラウドサービスはおよそ3000種類ほどありますが、そのほかにも自社開発のWebアプリケーションを登録して、Azure  ADのトークンを使ってアクセスさせるような作りこみも可能です。

■ ■ ■

Azure ADについて、もっと知りたいという方のためにこのブログがあります(だってURLがAzureAD.netですからね)ので、これからも色々な投稿を通じてお役に立てれば幸いです。

このコースでは、Office 365 をはじめとするクラウドサービスのユーザー認証の設計と実装について学習します。
Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編) | 株式会... - 株式会社イルミネート・ジャパン

ADFSから段階的にAzure ADへ移行

$
0
0

皆さんこんにちは。国井です。
オンプレミスActive Directoryの認証結果に基づいてAzure ADへのサインインを省略するシングルサインオン(SSO)機能を実装する場合、これまではADFSサーバーを使っていました。
ですが、最近ではAzure AD Connectで提供されるシームレスシングルサインオン機能によって代替できるようになったため、ADFSサーバーからシームレスシングルサインオン機能に切り替えたいという声も聞くようになってきました。

そこで今回は直近で登場したばかりのADFSサーバーからのステージドマイグレーション機能を利用して、段階的にADFSを利用するユーザーをシームレスシングルサインオンに切り替える方法を紹介します。

おさらい:SSOの条件

Azure ADに作られたユーザーアカウントを利用してサインインする場合、これまで3つの方法がありました。

1つめはAzure ADに直接作成したユーザーでサインインする方法、
2つめはAzure AD Connectを利用してActive Directoryから同期したユーザーでサインインする方法、
そして、3つめはAzure AD Connectを利用してActive Directoryから同期したユーザーを利用してADFSサーバーでSSOアクセスする方法です。

image

3つめの方法は2つめの方法が前提となって利用可能なサインイン方法です。

3つめの方法でAzure ADに対するSSOアクセスを行う場合、Azure ADに登録されたドメイン名の単位で判定をしていました。
Azure ADにカスタムドメイン名として会社のドメイン名を登録したら、そのドメイン名をSSOで利用するドメインとして設定すると、カスタムドメイン名画面ではフェデレーションの欄にチェックが付きます。

image

その結果、xxxx@adfs.jp のようなユーザー名でサインインしたときに、adfs.jp ドメインがフェデレーションドメインだとわかると、ADFSサーバーへリダイレクトしてSSOアクセスの処理を開始していたのです。

おさらい:ADFSサーバーの廃止設定

特定のドメインに対するADFSサーバーの利用を止める場合、Convert-MSOLDomainToStandardコマンドレットを実行します。
すると、SSOアクセスは廃止され、Azure ADに同期されたユーザーのユーザー名とパスワードを入力してサインインする方式に切り替わります。

image

このとき、事前にシームレスシングルサインオンの設定をしておけば、Convert-MSOLDomainToStandardコマンドレットを実行することで、自動的にADFSサーバーからシームレスシングルサインオンにSSO方式が切り替わります。

image

段階的な切り替え

Convert-MSOLDomainToStandardコマンドレットを実行すればシームレスシングルサインオンに切り替えることができます。しかし設定はドメイン単位なので、基本的にすべてのユーザーの移行をいっぺんに行わなければなりません。それはIT管理者の立場からしてみれば、とてもリスクの大きい作業だと感じることでしょう。
そこで、Azure ADでは新しく一部のユーザーだけをADFSサーバーからシームレスシングルサインオンに切り替える段階的な移行方法をサポートするようになったのです。

image

では設定を見てみましょう。
Azure AD管理センター画面(https://aad.portal.azure.com)から[Azure AD Connect]をクリックし、[マネージドユーザーサインインの段階的なロールアウトを有効にする]をクリックします。

image

[段階的なロールアウト機能を有効にする] 画面で、パスワードハッシュ同期またはパススルー認証を選択し、移行対象となるユーザーをグループの単位で指定します。

image

ご覧のような感じでグループの選択を行ったら終わり。

image

これだけです。次回からサインインするときはADFS経由ではなく、シームレスシングルサインオンによるサインインになります。
ちなみに、この方法による移行方法は完全にADFSをやめてしまうわけではないので、
PowerShellコマンドレットで、Get-MsolDomainFederationSettingsコマンドレットを叩くと、今までのADFSサーバー設定が引き続き残っていることがわかります。

image

image

ADFSサーバーからシームレスシングルサインオンへの段階的な移行には、現状のADFSサーバーの状態に問題がないか確認したり、
クレームルールをAzure ADへどのように移行するか? Office 365以外で証明書利用者信頼に登録されているクラウドアプリがある場合にどうやってAzure ADへ移行するか?
など検討しなければならない課題は色々あります。2020年にはこれらをまとめて学べるトレーニングコースを提供予定ですので、出来上がりましたら、改めてご案内させていただきます。

・参考URL
AAD Connect Healthを利用したADFSサーバーの監視
http://azuread.net/2015/08/21/aad-connect-health%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%9Fadfs%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%AE%E7%9B%A3%E8%A6%96/

CSVファイルからAzure ADユーザー作成

$
0
0

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

Azure ADでユーザー作成を行うとき、Active Directoryをお持ちの会社であればAzure AD Connectを使うことが多いと思います。一方、会社でActive Directoryを使っていない場合、CSVファイルを使ってまとめてユーザーを作成する、という方法をとるのが一般的だと思います。

CSVファイルからAzure ADユーザーを作成する場合、今までであればCSVファイルをWindows PowerShellから読み込ませて.. というやり方をしていたのですが、最近ではGUI画面から簡単に登録できるようになっているので、その方法を紹介します。

CSVテンプレートの取得と作成

最初に行うことはAzure ADのフォーマットに沿ってCSVファイルを作成することです。
CSVファイルのテンプレートは https://aad.portal.azure.com/ にアクセスして、ユーザー一覧にアクセスします。
[一括作成]をクリックすると、ユーザー作成の画面に移動できます。

image

そこで、[ダウンロード]ボタンをクリックすると、テンプレートファイルをダウンロードできます。

image

ダウンロードしたテンプレートファイルはメモ帳で開くと(Excelで開くと文字化けするので注意)、ご覧のようなファイルが開きます。
image

上の図は右端で折り返しているのでわかりにくいですが、1行目と2行目に字がかいてありますが、これはそのままにして、3行目以降に作成したいユーザーの情報を入れていきます。

必須入力項目は名前(表示上の名前)、ユーザー名、初期パスワード、サインインのブロックまでです。なお、サインインのブロックには「はい」という文字を入れておくと有効なユーザーとして作成されます。「サインインのブロック=はい」が有効??って思うかもしれませんが、サインインのブロックとはaccountEnabled属性のことなので、accountEnabled=True(はい)なら有効なユーザーというのも納得ですよね?(「じゃあなんでサインインのブロックなの?」とか聞かないでください)

そのほかの項目は任意なので空欄にして構いません。
ただし、後述しますが利用場所は入れておいたほうがいいです。ちなみに日本の場合はJPと入力しましょう。
設定できたらファイルを保存します。この時のポイントは文字コードをUTF-8 (BOM付き)で保存すること。メモ帳で保存すれば文字コードを一緒に設定できます。

ファイルを保存し、前の画面で[csvファイルをアップロードします]からファイルを登録すると、ユーザー作成が始まります。ユーザー作成の結果はユーザー一覧の画面で確認できるほか、ユーザー画面の[一括操作の結果]からも確認できます。

image

課題

CSVファイルでユーザーがまとめて作成できるのは便利なのですが、今までPowerShellで行っていたことが完全に代替できるかと言われれば、それは(今の時点では)違うと思います。その最たるものはライセンス割り当てです。作成したユーザーに一括でOffice365のライセンスを割り当てるという操作は普通によくあることだと思いますが、それはGUIからというのも大変ですよね。ということなので、今までどおりPowerShellからライセンス割り当てするのが現実的かな?と思います。

皆さんこんにちは。国井です。Azure ADのPowerShellもVersion 2が出てきており、そろそろ実務でも使う機会が出てきているので、このあたりで一度、主なコマンドレットをまとめておきたいと思います。(というか、自分用?)■まずはAzure AD PowerShell v2の実装以下の...
Azure AD PowerShell v2チートシート - Always on the clock

ライセンス割り当てするときには、ユーザーの属性で利用場所が設定されていることが前提条件になるので、ユーザー作成時に利用場所の設定も一緒に行っておくとよいでしょう。

このコースでは、Office 365 をはじめとするクラウドサービスのユーザー認証の設計と実装について学習します。
Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編) | 株式会... - 株式会社イルミネート・ジャパン

Azure ADの新しいアクセスパネル

$
0
0

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

最近はAzure ADのアップデートが多く、私が登壇させていただいているトレーニングの中でも、すべてのアップデートをお伝えすることが難しくなってきているので、今日はこちらで紹介をさせてください。Azure ADに関連付けられたクラウドサービスへのアクセスに利用するクライアントポータルサイトである、アクセスパネルについてです。

アクセスパネルはこれまで https://myapps.microsoft.com/ のURLで親しまれてきましたが、新しく https://myapplications.microsoft.com/ が用意され、見た目も変わっています。

8

ただし、変わったのは見た目だけではなく、新しくビューが作れるようになりました。
これまではすべてのアプリのアイコンが一覧で表示されるので、Office 365を使っているだけでもアイコンだらけの状態になっていたわけです。
そこで、新しいアクセスパネルではよく使うアイコンだけを並べることができるようになっています。
設定はAzure AD管理センター(https://aad.portal.azure.com/)の
[エンタープライズアプリケーション]から[ワークスペース]を開き、

1

新しいワークスペースを作成します。ここでいうワークスペースというのが「お気に入りのアイコン」グループだと思ってください。
ワークスペースの名前を設定したら

2

続いてワークスペースに並べるクラウドサービスを選択します。

3

次にワークスペースの所有者を選択します。ワークスペースの所有者になったユーザーはワークスペースの中に配置するクラウドサービス(アイコン)を自由に選択できるようになります。

4

次に作成したワークスペースを利用できるユーザーを選択します。ここで選択されたユーザーまたはグループはワークスペースを利用できるようになります。

5

ここまでで設定は完了です。

6

再び https://myapplications.microsoft.com/ にアクセスすると、ご覧のようにワークスペースが表示され、ワークスペース内には先ほど選択したクラウドサービスのアイコンだけが表示されていることがわかります。

7

タブをAll Appsに切り替えると、すべてのアイコンももちろんすべて表示されます。

8

さらに、新しいアクセスパネルページでは、右上のユーザーアイコンをクリックし、[マイアカウントの表示]をクリックすると、

10

Azure ADユーザーの個人に関わるセキュリティ情報の表示・カスタマイズができます。

11

ここも色々と説明することがあるのですが、別の機会に。

■ ■ ■

便利な機能であることはよくわかったのですが、一方でここまでのカスタマイズができるのであれば、ブラウザーのお気に入りみたいにユーザー自身がカスタマイズできるような機能もあったらいいですよね。
ということで、Azure ADのフィードバックサイトに書き込んでおきました。

New access panel (https://myapplications.microsoft.com) can customize display icons by workspace owner only. Unfortunately, end users want to customize it like browsers' favorites.So would you like to create personal workspace and can edit an...
Access panel should customize by user - Customer Feedback for ACE Community Tooling

ご賛同いただけるかた、投票のほどよろしくお願いいたします。

Office 365 とクラウドサービスの認証ベストプラクティス 2020年前半の日程

$
0
0

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

500回目となるブログの投稿は「Office 365とクラウドサービスの認証ベストプラクティス」コースの2020年前半の日程での開催についてです。2020年は6月までに以下の3回を追加開催することになりました。

2月25日~27日
5月11日~13日
6月29日~7月1日

週初めの開催が多くなってしまい、すみません。

これまでの開催について

他のトレーニングとは異なり、皆さんにどんなことを学習したいかを伺い、それに合わせて時間を使っていくようなスタイルで開催しています。テキストの内容よりも、皆さんにとって知りたいことを持って帰っていただけることが一番ですしね。
一方、基礎から知りたいという方にとっては「これを知りたい」というのを持っていない方もいるかもしれません。その場合でも、他の受講者の方々がお話していることを聞くだけでも、他の人がどんなことで困っているかなど、参考になることが色々あると思うのです。

Azure ADをこれから導入する方、案件で抱える方、お悩みの方など、色々な方のご要望を満たせるように尽力しますので、ぜひご検討ください。
コースの詳細情報は以下のリンクからご覧いただけます。

このコースでは、Office 365 をはじめとするクラウドサービスのユーザー認証の設計と実装について学習します。
Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編) | 株式会... - 株式会社イルミネート・ジャパン

Azure ADのアプリの登録とは

$
0
0

皆さんこんにちは。国井です。
今日はAzure ADの管理メニューにある
[アプリの登録]ってなに?
どう使うの?
についてみていきます。

■ ■ ■

Azure ADを利用する目的っていろいろあると思いますが、多くの方が様々なアプリへのシングルサインオンを実現したいという目的を持っているのではないかと思います。
ここでいう「アプリ」にはSaaS型のクラウドサービスの場合もあれば、PaaSで動作するWebアプリケーションだったり、IaaSの仮想マシンだったりする場合もあるでしょう。

SaaS型のクラウドサービスの場合はSAMLプロトコルを使ってシングルサインオンを実現する「エンタープライズアプリケーション」という設定があるので、これを使います。
これに対して主にWebアプリケーションで認証を行いたい場合や、Webアプリケーション経由でマイクロソフトのクラウドサービスへAPIアクセスしたい、などというときに利用するのが「アプリの登録」というメニューです。

WebアプリケーションからAzure ADで認証をさせてもらう場合、Azure ADからしてみれば、誰だかわからないWebアプリケーションからの認証要求は受け付けたくありません。
そこで、Azure ADでは「アプリの登録」という機能を使ってあらかじめ登録されているWebアプリケーションからであれば認証要求は受け付けるよ!という機能なのです。
ちなみに、このような機能のことを一般的な用語ではサービスプリンシパルと呼んでいます。
ですので、アプリの登録というのはサービスプリンシパルのことなのです。

実装して使い方を確認

他のブログなどでもアプリの登録を使ったWebアプリケーションの登録方法は紹介されているので、ここでは最も簡単にWebアプリケーションを登録し、動作する様子を見てみましょう。

今回用意する材料は次の通りです。

・Webアプリケーション
・Windows Server
・Azure AD

まずWebアプリケーションですが、GitHubにSingle Page ApplicationタイプのWebアプリケーションがあるので、これを入手しましょう。ファイルはapp.js, index.html, msalconfig.js の3つが必要です。

Microsoft app Demo. GitHub Gist: instantly share code, notes, and snippets.
Microsoft app Demo - Gist

続いてWindows Serverですが、バージョンは何でもいいです。インターネットにつながる環境のWindows Serverを用意しましょう。

用意できたらIISをインストールしておいてください。IISをインストールするときはCGIも一緒にインストールしておきましょう。

無題1

IISのインストールが完了したら、前にダウンロードしたapp.js, index.html, msalconfig.js の3つのファイルをIISをインストールしたサーバーに保存しておきます。ここではc:\spaフォルダーを作って保存しておきました。

次にIISでWebサイトを追加します。c:\spaをサイトのルートとなるような、ご覧のようなサイトを作りました。

無題2

アプリの登録を設定

ここまでの準備ができたら、いよいよアプリの登録を作成します。IISのWebサイトに対応するように、Azure ADの[アプリの登録]からWebアプリケーションを登録します。
無題3

アプリの登録画面ではIISのWebサイトへのURLを[リダイレクトURI]に登録します。このとき、localhostを設定していますが、localhost以外のURLになるとhttpsでなければなりません。そうなると、証明書を用意して、、とか面倒なことになるので、今回はlocalhostにしました。

無題4

登録が完了したら、クライアントIDが生成されるので、これを控えておきましょう。
(ちなみに今回の実装ではクライアントIDだけあればOKですが、一般的なケースでは他のパラメータも必要になります。他のたいていのパラメータは[エンドポイント]というボタンから入手できます)

無題5

それから今回の実装ではOAuth2.0のインプリシットフローと呼ばれる処理を行います。そのため、インプリシットフローに合わせた設定を行うので、アプリの登録内の[認証]項目から[アクセストークン]と[IDトークン]にチェックを付けておきます。

無題9

IISのWebサイトに戻ります。
前にコピーしたmsalconfig.jsファイルを開いて、クライアントIDを張り付けてください。

無題6

ここまでの設定で、Webサイトとアプリの登録の間での連携は完了です。
早速アクセスしてみましょう。
作成したWebサイトのURLにアクセスして、

無題7

ボタンを押すと、Microsoft GraphというAPIを使ってAzure ADユーザーのプロファイル情報を収集しようとするので、この時点でAzure ADの認証が始まります。

無題8

認証が完了すると、初めてアクセスするときだけ「同意」の画面が表示されます。
[承諾]ボタンを押してアクセス許可を与えると、

無題10

ご覧のようにAzure ADにAPIアクセスして、その結果(プロファイル情報)がブラウザに表示されたことがわかります。

無題11

このようにアプリの登録を利用してAzure ADとWebアプリケーションの関連付けすることで、Webアプリケーションの認証・認可にAzure ADが簡単に利用できるようになるのです。

【参考】
https://github.com/MicrosoftDocs/azure-docs.ja-jp/blob/master/articles/active-directory/develop/active-directory-how-applications-are-added.md

Microsoft 365の活用方法を学ぶ、新しいトレーニングコースが始まります!

$
0
0

皆さんこんにちは。国井です。
今日は新しいトレーニングコースの紹介です。

イルミネート・ジャパンさんで提供しているトレーニングコースでは現在「Office 365とクラウドサービスの認証ベストプラクティス」コースがありますが、こちらのコースに加えてMicrosoft 365の勝つ方法について知りたいというニーズを受け、2つの新しいトレーニングコースを弊社から提供することになりました。

Microsoft 365 を利用したインシデント対応 (CI535-H)

Microsoft 365はサービスが提供開始されてからだいぶ時間が経ち、知名度もそれなりに上がってきたかと思います。そのせいか最近は「Microsoft 365でセキュリティ対策というけど、具体的に何をすればよいかわからない」というご相談をいただきます。
特にMicrosoft 365 E5の機能で提供されるAdvanced Threat Protection (ATP) の名前が付いたサービス群はどうやって使えばよいのか、よくわからないという話を聞きます。
Office 365 ATPを例に出せば、ご覧のような自動でインシデント対応してくれる機能がありますが、これを見せられて何をすれば良いかわからないこともあるでしょうし、また自分がやっていることに自信が持てない方もいるでしょう。

atp3
そこで、このコースではMicrosoft 365のサービスのうち、ATPに特化して社内でインシデントが発生した時にどのように対処すべきかについて学習します。
インシデント対応はセキュリティベンダーが行う作業と考えている方もいらっしゃるかと思いますが、マネージドサービスを利用したり、スポットで毎回フォレンジックを依頼するのもなかなかコストがかかるもの。
ATPはセキュリティベンダーの人でなくてもインシデント対応ができることを目標に作られているサービスなので、自社でSOCを立ち上げたい、Microsoft 365 E5を利用して運用したいという方に具体的な利用方法から運用方法までを学んでいただけるようなものを作ってみました。
特徴はとにかく色々な攻撃を実際に起こして、様々なアラートを見ていただけるようにした点です。実際に発生するアラートに見慣れておけば、自社に戻って現実にアラートが発生したとしても行うべき作業がクリアになるのではないかと思っています。

Microsoft 365 が提供するインシデント対応機能の概要を理解し対応ができるスキルを身に着けていただけます。
Microsoft 365 を利用したインシデント対応 | 株式会社イルミネート・ジャパン - 株式会社イルミネート・ジャパン

初回の開催は2020年4月27-28日の予定です。

 

EMS で実現するクラウド IT インフラ管理 (CI532-H)

オンプレミスからクラウドへのシフトが起こりつつある時代の中で、クライアント管理や社内インフラ管理もクラウドへ移行していくことが予想されます。
キッティング作業、ポリシー管理、ファイルサーバー管理、更新プログラム管理など、社内ITとしてこれまで行ってきた作業を

image

Microsoft 365を使ったクラウドサービスに移行しようとしたときにどのような移行方法をとればよいか?また、その時の注意点は何か?などを実際にクラウドITインフラ基盤を作りながら学んでいきます。

こちらのトレーニングコースは今回、私の会社の同僚でMicrosoft 365分野のMicrosoft MVPでもある新井慎太朗さんにお願いすることにしました。

Microsoft 365 が提供するインシデント対応機能の概要を理解し対応ができるスキルを身に着けていただけます。
EMS で実現するクラウド IT インフラ管理 | 株式会社イルミネート・ジャパン - 株式会社イルミネート・ジャパン

初回開催は2020年6月25日-26日の予定です。

また、これから徐々に関連コンテンツもご紹介してまいりますので、お楽しみに!

2020年版Azure ADログ取得方法あれこれ

$
0
0

皆さんこんにちは。国井です。
Azure ADのサインインログは最大で30日までしか登録されないことはこれまでにも何回も紹介してきました。

皆さんこんにちは。国井です。早いもので、もう9月。夏休みの思い出は何か作れましたか?私は海にも、山にも行かず、夏休みを消化することもなく、8月が終わってしまいました。。そんなことより、今日はAzure ADのアクセス監視に関する話です。Azure ADをID管理シス...
Office 365 × Azure ADのアクセスログとアクティビティ監視(1) - Always on the clock
皆さんこんにちは。国井です。Azure ADの研修サービスを提供させていただく中で、色々なお客様からのご要望の多い「最大で30日しか保存されないレポートをどうするか?」問題。以前、私はPowerShellスクリプトを作ってローカルにダウンロードしておきましょうという...
PowerShellからAzure ADレポートのエクスポート - Always on the clock
皆さんこんにちは。国井です。 先日、たまたまPower BIを利用する機会があり、ソースにAzure Acti…
Azure ADのサインイン履歴をPower BIで可視化した場合の実力をチェック - Always on the clock

その都度、スクリプトを書いたり、色々やって「永続的にログを残す方法として、こんなやり方あるよ」って紹介してきたわけですが、最近Azure ADのログを収集するのに使っていたGraph APIがMicrosoft Graphに変わってしまったため、以前ブログで紹介したようなやり方が通用しなくなってしまったのです。

そこで2020年の今、利用可能なAzure ADのログ収集方法をまとめておきますので、参考になれば幸いです。

Microsoft Azureにエクスポート

この方法が最も持続性のある、やり方です。
だってAzure ADとMicrosoft Azureの両方にお金払っているのですから。

皆さんこんにちは。国井です。最近、Azure ADのトレーニングの中でログについてご質問をいただくことが多くなってきました。Azure ADのログはPremiumの契約を結ばないと見られないことや、Premiumの契約があったとしても30日までしか保存されないなど、いろいろ課題...
Azure MonitorでAzure ADを監視 - Always on the clock

ちなみに、このエクスポートの応用系としてAzure Sentinelを使ったSIEMによる分析方法があったりします。

Azure ADレポート用PowerShellコマンドレット

これを書いている現在はまだプレビューですが、Azure ADのログを収集する専用のPowerShellコマンドレットがあります。

レポート用の Azure AD PowerShell コマンドレットのリファレンス。
レポート用の Azure AD PowerShell コマンドレット - docs.microsoft.com

最初にコマンドレットのインストールと接続を行い、

Install-module AzureADPreview
Connect-AzureAD

その上で、監査ログを収集したければ Get-AzureADAuditDirectoryLogs コマンドレット
サインインログを収集したければ Get-AzureADAuditSignInLogs コマンドレット
それぞれ実行するだけです。

ただ、Get-AzureADAuditSignInLogs コマンドレットは私の環境だと、
-Filterオプションが使えず、Get-AzureADAuditSignInLogs -Top 10 のように
直近10個のログみたいな収集しかできないんですよね..

PowerShellスクリプトからMicrosoft Graphへ接続

Azure ADレポート用PowerShellコマンドレットがしっかり使えるようになれば、もう要らない方法かもしれないですが、PowerShellからMicrosoft Graphへ接続したい!というニーズは今後もあるでしょうから
ここにやり方を残しておきます… と思ったら、既にMSさんのページに方法が書いてありました。

やり方を要約すると、次のとおりです。

 

1.自己署名証明書の作成
2.MS Graphへの接続に必要なツールのダウンロード
3.MS Graphへの接続に必要なアプリの登録
4.スクリプトを実行してログを取得

このうち、3.のアプリの登録部分が上記のページで端折った感じで書かれていたので、ここで少し補足しておきます。

まず、Azure AD管理ポータルから[アプリの登録]にアクセスし、新しくアプリを作成します。
このときに入力するURLはなんでもいいのですが、ここでは http://localhost としています。

image

アプリの登録ができたら、[APIのアクセス許可]からログにアクセスするために必要なアクセス許可を設定します。[アクセス許可の追加]をクリックして、

image

Microsoft Graphをクリックして、

image

[AuditLog]の中から[AuditLog.Read.All]を選択します。

image

アクセス許可を追加できたら、[管理者の同意]をクリックしておきます。

image

続いて、[証明書とシークレット]に進み、手順1.で作成した証明書を登録します。
登録には証明書の拇印が必要になりますので、1.で作成した証明書(.cer)ファイルをダブルクリックして、拇印の番号を控えておいてください。

image

登録が完了すると、1.で作成した証明書を利用してスクリプトを実行するようになります。
つまり、証明書を作成したコンピューターからのみスクリプトが実行可能な状態になります。

image

最後に[概要]をクリックして、クライアントID、テナントIDを控えておきます。

image

ここまでの設定ができたら、上記のMSサイトに公開されているスクリプトにここまでで控えておいた情報を入力し、実行するだけ。
すると、ご覧のようにログが取得できます。

image

このやり方をマスターすれば、Microsoft Graphを利用する、他の情報収集にも使えそうですね。
またの機会にチャレンジしてみたいと思います。

■参考情報

Azure AD Reporting API にアクセスするための前提条件の詳細
Azure Active Directory レポート API の前提条件 - docs.microsoft.com
Microsoft Graph API からのサインインリソース (エンティティ) の get メソッドについて説明します。
サインインを取得する - Microsoft Graph v1.0 - docs.microsoft.com

 

 

Microsoft Graph APIでAzure ADを管理

$
0
0

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

前回、Azure ADのログ管理方法を紹介したところ、Microsoft Graphと呼ばれるAPIを使った管理について、いくつかご意見をいただきました。その中のひとつで、皆さんにも共有しておこうと思ったのが、[アプリの登録]を使うときに証明書ではなく、シークレットを使う方法です。

ちょうど、MSさんのサイトでMS Graph経由でAzure ADのログを取得する方法があり(前回も紹介しましたね)、ここで証明書を使う方法が紹介されていました。

ただ、このやり方だと証明書の管理をしなければならないので、もっと手軽に利用したいというニーズがあるわけです。
そこでシークレットを使うのです!

シークレットは単なる文字列なので、知っている人であれば、いつでもどこでもAPIアクセスができるという便利な仕組み。なので、API経由でちょっとした管理を行いたいという人には喜ばれるのではないかと思います。
(ただし、シークレットは他人に知られたらいけませんので、管理は厳重に!)

設定も簡単で、前回紹介した証明書を登録する画面で、証明書の代わりに[新しいクライアントシークレット]を押してシークレットを生成するだけ。

image

生成したシークレットはPowerShellスクリプトの中で指定するだけでOKです。
前述のMSサイトの中に書かれているスクリプトで言うと、以下の部分を変える感じです。
ちなみにxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx部分にクライアントシークレットの文字列が入ります。また、#$cert =で始まる行(22行目)も不要なので削除してください。(下記のスクリプトでは#で最初からコメントアウトしているので、削除しなくても一応動きます)

Add-Type -Path ".\Tools\Microsoft.IdentityModel.Clients.ActiveDirectory\Microsoft.IdentityModel.Clients.ActiveDirectory.dll"
#
# Authorization & resource Url
#
$tenantId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 
$resource = "https://graph.microsoft.com" 
$clientID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$clientsecret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
$outfile = "output.csv"
$data = @()
# tenantID は [Azure Active Directory] - [プロパティ] よりディレクトリ ID を取得します。
# clientID は "Azure AD Reporting API にアクセスするための前提条件" の "アプリケーションのクライアント ID を取得する" の手順で取得します。
# thumbprint は公開キーのアップロードを実行後の "キー" のページで "公開鍵" にサムプリントとして表示されている情報です。
#
# Authorization & resource Url
#
$authUrl = "https://login.microsoftonline.com/$tenantId/"
#

# Get certificate
#
#$cert = Get-ChildItem -path cert:\CurrentUser\My | Where-Object {$_.Thumbprint -eq $thumprint}
 
#
# 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
#
(以下省略)

これでできあがりです。

Microsoft GraphでAzure ADへアクセス

やっと本題です。ここまで紹介した仕組みを使ってAzure ADのログにアクセスできるのであれば、Azure ADのもっと違うデータにアクセスすることもできるのではないか?と思ったかもしれませんが、まさにその通りです。
Microsoft GraphではAzure ADに格納されている様々なデータにアクセスできるだけでなく、Azure ADに対する設定であったり、Microsoft Intuneなどの他のクラウドサービスに対する操作などもできてしまうのです。
今日はサンプルとして、Azure ADユーザーが利用している多要素認証の方法(音声通話、SMS、Authenticatorアプリなど色々ありますよね)を調べてみたいと思います。

必要なデータにアクセスするためのAPIを調べる

Microsoft Graphで提供するAPI一覧とそれぞれのAPIでアクセス可能なデータ一覧はマイクロソフトのAPIリファレンスサイトで紹介していますので、まずはこれで調べましょう。

このセクションのリファレンス コンテンツは、Microsoft Graph ベータ版のエンドポイントを文書化しています。 ベータ版のエンドポイントには、現在プレビュー段階で一般提供されていない API が含まれます。 これらの API を試して、次のチャネルからフィードバック...
Microsoft Graph ベータ版のエンドポイント リファレンス - Microsoft Graph beta - docs.microsoft.com

ちなみに多要素認証で使う認証方法の情報はReports.Read.AllとAuditLog.Read.Allの2つで、APIを呼び出すときは
https://graph.microsoft.com/beta/reports/credentialUserRegistrationDetails
のように書きます(と、APIリファレンスサイトに書いてありました)。

 

なお、APIでどれを使えばよいかわからない場合はGraphエクスプローラーを使って調べるのもお勧めです。

image

アプリの登録を作成

Reports.Read.AllとAuditLog.Read.Allの2つのAPIを利用できるアプリの登録を作成します。
前回紹介した方法で[アプリの登録]を作成し、APIのアクセス許可を割り当てておきましょう。

image

PowerShellスクリプトの作成

最後にPowerShellスクリプトを作成します。
スクリプトは前述のMSサイトを参考に次のように作ってみました。
環境によって

$tenantId = 以降の部分にAzure ADのテナントID
$clientID = 以降の部分にクライアントID (アプリケーションID)
$clientSecret = 以降の部分にクライアントシークレット

に書き換えてください。
また、APIアクセスのURLは最後から5行目(44行目)の部分で指定していますが、
もし違うデータにアクセスしたければ、
/beta/reports/credentialUserRegistrationDetails の部分を違うURLに書き換えてください。 

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

##
## 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
# Get data from MS Graph
if ($null -ne $authResult.AccessToken) {
     $headerParams = @{'Authorization' = "$($authResult.AccessTokenType) $($authResult.AccessToken)"}
     Invoke-RestMethod -Uri "$resource/beta/reports/credentialUserRegistrationDetails" -Headers $headerParams -ContentType “application/json” | select -ExpandProperty value
}
else {
     Write-Host "ERROR: No Access Token"
}

実行結果がこちら。

ご覧のようにユーザーごとに多要素認証で利用している認証方法がauthMethodsプロパティに表示されていることがわかります。
もうちょっと見やすく表示するならスクリプトの最後から5行目を次のように変えるのもひとつの方法です。

Invoke-RestMethod -Uri “$resource/beta/reports/credentialUserRegistrationDetails” -Headers $headerParams -ContentType “application/json” | select -ExpandProperty value | ft UserDisplayName, authMethods -Autosize

この場合の実行結果はこちら。

image

今回は参照するところに注力しましたが、もちろんPowerShellですからCSV形式にして他のアプリと連携したり、Invoke-RestMethod –Method POST… と書いてAzure ADに対する設定を行ったり、色々なことに応用できると思います。

Office 365 とクラウドサービスの認証ベストプラクティス 2020年4月の追加開催決定

$
0
0

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

「Office 365とクラウドサービスの認証ベストプラクティス」コースの2月の開催ですが、
申し込み多数につき、現在お申し込みの相談をされている方までを持って締め切らせていただきました

正直、物理的な座席自体はまだ余裕があります。
ただ、このコースは参加される方からご要望を伺い、
それに合わせて進めていったりする関係上、
どうしても多くの方を招くことができないのです。

また、受講者の方々の間でも情報共有されたりする上でも、
受講者数が多すぎることはマイナスに作用するようにも思うので、
申し訳ないですが、締め切らせてください。

代わりというわけではありませんが、2020年4月8-10日の日程での
追加開催を設定しましたので、こちらも併せてご検討いただければと思います。

このコースでは、Office 365 をはじめとするクラウドサービスのユーザー認証の設計と実装について学習します。
Office 365 とクラウドサービスの認証ベストプラクティス (Azure AD 編) | 株式会... - 株式会社イルミネート・ジャパン

5月11~13日と6月29日~7月1日にも開催を設定しておりますので、
こちらと合わせてご検討くださいませ。

Viewing all 439 articles
Browse latest View live