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

Microsoft Intuneの設定をPowerShellから行う

$
0
0

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

最近、Microsoft Intuneに関するお問い合わせが多くなっており、
セミナーをやってほしいとのご連絡をいただくことも多くなってきました(ありがたいことです)。

そこで、今日はMicrosoft Intuneの話をしようと思います。
具体的にはPowerShellからMicrosoft Intuneを操作する方法についてです。

Microsoft IntuneはGUIからの操作をサポートしており、それはそれで便利なのですが、PowerShellからまとめて設定できるような方法もあってほしい、との声をよく聞きます。
そんなあなたのためにIntuneにはGraph APIを経由して操作する方法が用意されており、これをPowerShellから操作することで、やりたいことの多くは実現できると思います。

■Intune APIs in Microsoft Graph – Now generally available
https://cloudblogs.microsoft.com/enterprisemobility/2018/01/31/intune-apis-in-microsoft-graph-now-generally-available/

Graph APIを利用する場合には、Azure ADに専用のアプリを作り、そこからOAuth 2.0を利用してIntuneにアクセスするという仕組みを事前に作っておきます。
設定方法は、、って説明しようと思ったらMSのサイトに解説が書いてあったので、そちらを参考にしてください。

■Azure AD を使用して Microsoft Graph の Intune API にアクセスする方法
(Microsoft Graph API を使用するアプリを登録する」部分参照)
https://docs.microsoft.com/ja-jp/intune/intune-graph-apis

なんでGraph APIとMicrosoft Intuneの話にAzure ADが絡んでくるの?
まず、Graph APIでMicrosoft Intuneにアクセスする場合、誰でもアクセスできては困るので、認証と認可を事前に行わなければなりません。Microsoft Intuneでは、そもそも利用するのにAzure ADを使って認証・認可をしていましたよね?だから、Azure ADを使うのです。
ここまでは誰でもわかることだと思います(ちなみにOAuth2.0を使った認可の仕組みを実装しています)。

次に、出てくる疑問として、Microsoft Intuneの認証・認可にもともとAzure ADを使っているのに、Microsoft IntuneをアプリケーションとしてAzure ADに登録するか?ってことです。これはこう考えるとよいでしょう。
オンプレミスの配置されたサーバーにアクセスするとき、Active Directoryドメインを使って認証・認可を行うと思います。このとき、サーバーへのアクセスにActive Directoryが利用できるかどうかは、事前にドメインに参加しているかどうかで決まります。サーバーをドメイン参加させておくことでActive Directoryによる認証・認可ができるのです。それと同じように、Microsoft IntuneでもAzure ADにアプリケーションとして登録しておく(つまり、この行為がオンプレミスのドメイン参加に相当すると思えばよいでしょう)ことで、Azure ADを使って認証を行い、そしてどこまでのアクセスを許可するかを決定(つまり、認可ですね)することができるのです。
だからこそ、Microsoft Intuneを利用するのであれば、Azure ADにアプリケーションとして登録する必要があるのです。

アプリができたら、PowerShellからアクセスするのですが、何を書けばいいかわからない、という問題にぶち当たります。ですが、そこもPowerShellのサンプルがGitHubにあがっているので、これを使えば簡単(?)です。

■GitHub powershell-intune-samples
https://github.com/microsoftgraph/powershell-intune-samples

色々なサンプルが用意されているのですが、今日はこの中からIntune登録デバイスのプロパティに設定されている[デバイス所有者]の設定を個人から企業に設定変更する方法についてみてみます。

image

デバイスのプロパティにある[デバイス所有者]の設定は、単なるプロパティ情報ではなく、企業の端末に設定されているときだけリモートワイプが設定できるようになるなど、他のIntuneの機能にも影響が及ぶので、ぜひ押さえておきたい設定です。

■Intune のリモートワイプとリモート パスコードリセット機能は「会社所有端末」のみを対象に発行できるようになります
https://blogs.technet.microsoft.com/jpintune/2018/10/23/wipeandpasscodeforcompanydevicesonly/

話が少しそれてしまいましたが、もとに戻して、Intune用のPowerShellサンプルを実行するときは、そのデバイス上で事前にAzure AD PowerShellをインストールしておく必要があります。

Install-Module AzureAD

上記のコマンドを入力し、実行します。

実行できたら、続いて[デバイス所有者]の設定に必要なデバイスの情報を収集します。デバイスの情報は、サンプルの ManagedDevices > ManagedDevice_Get.ps1 を使います。
ファイルの内容をPowerShell ISEにペーストし、実行すると、ご覧のように個々のデバイスの詳細データが出てきます。

image

これをもうちょっと見やすくするには、

Get-ManagedDevice | ft deviceName, id, managedOwnertype

のように実行すればよいでしょう。

image

これで、デバイス名に対応するIDを確認できたら、いよいよ[デバイス所有者]の設定を変更します。
設定変更は、サンプルの ManagedDevices > ManagedDevice_DeviceOwnership_Set.ps1 を使います。
これまたファイルの内容をPowerShell ISEにペーストし、実行します。
単純に実行しても何も起きないので、改めてSet-ManagedDevicesコマンドレットをデバイスのIDと[デバイス所有者]設定を企業(company)になるように設定します。

Set-ManagedDevices –id xxxxxx –ownerType company

すると、デバイス所有者がcompanyに変わったことが確認できます。

image

こんな感じで設定変更できます。

★おまけ★

Set-ManagedDevicesコマンドレットですが、スクリプトの中身を見ると、
287行目の部分で、JSON形式でIntuneに渡してあげる項目と値が定義されていることがわかります。
image

ここを変更することによって、異なる設定項目を設定したり、異なる値を設定したりすることができます。


Microsoft Intuneの設定をPowerShellから行う(2)

$
0
0

皆さんこんにちは。国井です。2019年もどうぞよろしくお願いいたします。

前回、PowerShellからMicrosoft Intuneを操作する方法を紹介しましたが、
ブログを書いた後で、なんとPowerShellコマンドレットが用意されていることに気が付きました。

Intune-PowerShell-SDK
https://github.com/Microsoft/Intune-PowerShell-SDK

上記のサイトにも書いてありますが、
https://github.com/Microsoft/Intune-PowerShell-SDK/releasesからダウンロードすること
・.NET Framework 4.7.1以降が事前にインストールされていること
・Windows 10の場合、net471フォルダーにあるコンテンツを使うこと

という条件を満たすように構成します。
そのうえで、次のコマンドレットを実行してIntuneに接続します。
(Microsoft.Graph.Intune.psd1ファイルはnet471フォルダー内にあります)

Import-Module .\Microsoft.Graph.Intune.psd1
Connect-MSGraph

管理者の資格情報を入力すると、OAuth2.0の承諾画面が出るので、承諾しておきます。

imageimage

以上で設定は完了です。
利用可能なコマンドレットは
Get-Command –Module Microsoft.Graph.Intune と実行すれば確認できます。
なんと、その数914!

いくつかみてみましょう。

Intune登録デバイスの確認

Get-IntuneManagedDeviceコマンドレットを使います。

image

実行結果のうち、deviceName属性がデバイスの名前、deviceEnrollmentType属性がAzure ADへのデバイス登録方法(registered, WindowsAzureADJoinなど)、osVersion属性がOSバージョンをそれぞれ表します。

ポリシーの準拠状況の確認

Get-IntuneManagedDeviceDeviceCompliancePolicyStateコマンドレットで確認できますが、確認するデバイスのIDを指定する必要があるので、

Get-IntuneManagedDevice | Get-IntuneManagedDeviceDeviceCompliancePolicyState

のように指定します。

展開するアプリの確認

展開するアプリはGet-IntuneMobileAppコマンドレットを使います。
ただ、色々な情報が出てきて見にくいので、Get-IntuneMobileApp | ft displayName のように整形するとよいでしょう。

image

Graph APIのメソッドで直接アクセス

Intune用PowerShellコマンドレットを実行すると、内部的にはGraph APIを実行してアクセスしています。
Graph APIによる直接的なアクセスを行いたい場合、Invoke-MSGraphRequestコマンドレットを使います。
Graph APIではHTTPプロトコルのGETメソッドを使ってアクセスするので、
パラメーターとしてGETメソッドの指定、さらにアクセスしたい情報をURIで指定します。
例えば、前述の展開するアプリの確認をGraph APIで直接指定する場合、次のように指定します。

Invoke-MSGraphRequest -HttpRequest GET -Uri ‘deviceAppManagement/mobileApp/アプリID’

image

ちなみにアプリIDはGet-IntuneMobileApp | ft displayName, id コマンドレットを実行すれば確認できます。

デバイスに対するワイプ/リタイヤ等の操作

Intune管理デバイスに対して、ワイプやリタイヤ(セレクティブワイプ)、再起動などの操作はInvoke-IntuneManagedDevice*コマンドレットで実行できます。

image

例えば、再起動を実行する場合はInvoke-IntuneManagedDeviceRebootNowコマンドレットを実行します。デバイスの指定には、デバイスの名前ではなく、デバイスIDが必要になるので、先にGet-IntuneManagedDeviceコマンドレットでIDを調べておいてから実行します。

image

デバイス所有者の設定変更

デバイスに対して設定されたプロパティ情報を変更する場合もそれぞれの設定に対応したコマンドレットが用意されています。例えば、前回の投稿でも紹介したデバイス所有者情報を変更する場合はUpdate-IntuneManagedDeviceコマンドレットを使います。

image

■ ■ ■

今回紹介したコマンドレット以外にも、たくさんの操作が可能なので、ぜひ色々と試してみてください。

Azure AD管理権限の委任

$
0
0

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

Azure ADでもOUって作れますか?

これまでに多くの人に質問を受け、その都度「できるけど面倒ですよ」とお答えしてきました。
つい先日、「じゃあどうやって設定するのですか?」と聞かれ、あっさりネットで調べたら出てくるだろうと思っていたら、意外にも無かったので、ここに書き留めておくことにしました。

Azure ADの管理者ロールには、いくつかのものがありますが、全体管理者のロールが割り当てられているユーザーがAzure AD全体に対する管理ができるユーザーであることはご存知かと思います。
これに対して、一部のユーザー/グループだけを管理する、いわゆるOU的な管理のしかたをしたい場合、Azure ADではAdministrative Unit、略してAUというものが用意されています。

image

AUはOUと同じで、

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

の3つを設定すればよいのですが、AUはOUと違ってGUIから設定できません
これが冒頭に「できるけど面倒ですよ」と言った理由です。

じゃあ、今日は重い腰を上げて、その面倒な設定を行ってみることにしますか。

0. 準備

AUの設定はPowerShellから行います。Azure AD用のPowerShellモジュールは

Install-Module AzureAD

を実行すればインストールされます。
なお、インストール後にコンソールを閉じたので、再度ロードしたいというときは「Import-Module AzureAD」でどうぞ。
インストールが完了したら、「Connect-AzureAD」コマンドレットで接続しましょう。

1. AUの作成

AUを新規作成するときはNew-AzureADAdministrativeUnitコマンドレットを使います。例えば、US Officeという名前のAUを作る場合なら、こんな感じ。

New-AzureADAdministrativeUnit -Description "United States" -DisplayName "US Office"

実行すると、AUが作成されるのと同時にオブジェクトIDが割り当てられます。このIDが後で必要になるので、

$USOffice=Get-AzureADAdministrativeUnit | Where-Object{$_.displayname -match "US"}

$USOffice変数にセットしておきましょう。そうすれば後で$USOffice.ObjectIdって感じで呼び出せます。

2. AUのメンバーの定義

作成したAUのメンバーはAdd-AzureADAdministrativeUnitMemberコマンドレットを使います。ObjectIdオプションでAUのメンバーとなるユーザーやグループのオブジェクトID、RefObjectIdオプションでAUのオブジェクトIDをそれぞれ指定します。

Add-AzureADAdministrativeUnitMember –ObjectId <ユーザーのオブジェクトID> -RefObjectId $USOffice.ObjectId

もし、場所が米国に設定されているユーザー全員をAUのメンバーにしたいということであれば、

Get-AzureADUser -Filter "UsageLocation eq 'US'" | Foreach-Object{
Add-AzureADAdministrativeUnitMember –ObjectId $_.ObjectId -RefObjectId $USOffice.ObjectId
}

これでいけます。

3. AUの管理と管理権限の定義

AUに対して設定可能な管理権限(ロール)はHelpdesk AdministratorとUser Account Administratorの2つだけです。ですので、どちらのロールを割り当てるのですが、割り当て可能なロール一覧を見てみると、

image

いない!

ということで、ロールテンプレートから上記のロールを有効化するという手順が必要になります。まずはGet-AzureADDirectoryRoleTemplateコマンドレットでロールテンプレートに登録されているロールからUser Account AdministratorのオブジェクトIDを確認し、

image

Enable-AzureADDirectoryRoleコマンドレットで有効化します。

Enable-AzureADDirectoryRole -RoleTemplateId fe930be7-5e62-47db-91af-98c3a49a38b1

もう一度、Get-AzureADDirectoryRoleコマンドレットで確認すると、今度はUser Account Administratorが出てきます。
(テンプレートのオブジェクトIDとロール一覧のオブジェクトIDは異なるので注意)

image

それからロール割り当てをするとき、割り当てるユーザーをMicrosoft.Open.AzureAD.Model.RoleMemberInfoオブジェクトの変数にセットするという面倒なことをしなければなりません。
事前にGet-AzureADUser コマンドレットで管理ユーザーのオブジェクトIDを確認し、$user01変数にユーザーの情報をセットします。

$user01=Get-AzureADUser -ObjectId b013e28a-7cf6-4988-8929-cb3da96e721b

その上で、Microsoft.Open.AzureAD.Model.RoleMemberInfoオブジェクトの変数$RoleMemberをご覧のような感じで作ります。

$RoleMember = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo
$RoleMember.ObjectId = $user01.ObjectId

$RoleMember 変数ができたら、いよいよuser01@xxxxx ユーザーにUS Office AUを対象としてUser Account Administratorロールを割り当てます。
割り当てるときはAdd-AzureADScopedRoleMembershipコマンドレットを使います。
3a08e84c-4318-4cb7-a83e-dc5a6d8474f0というのはUser Account AdministratorのオブジェクトIDです。

Add-AzureADScopedRoleMembership -ObjectId $USOffice.ObjectId -RoleObjectId 3a08e84c-4318-4cb7-a83e-dc5a6d8474f0 -RoleMemberInfo $RoleMember

これで出来上がり。実際に該当のユーザーでサインインして、Microsoft 365管理センター (https://portal.office.com) にアクセスすると、

image

AUのメンバーとなっているユーザーだけがユーザー一覧に表示され、管理できることがわかります。

Windows Analytics 評価ガイドリリースされました

$
0
0

皆さんこんにちは。国井です。
リリースから相当時間が経ってしまいましたが、
Windows Analytics評価ガイドがリリースされましたので紹介します。

http://download.microsoft.com/download/7/F/F/7FFBDB2B-7BC4-4F64-97F1-1284600A992C/Windows_AnalyticsGuide_v1_5.pdf

Windows AnalyticsはWindows 10をはじめとするクライアントコンピューターの更新プログラム適用状況を把握するためのサービスで、スクリプトを実行するだけでクライアントの状況がAzureストレージの中に格納されるようになり、その結果をMicrosoft Azureの管理ポータルから視覚化した状態で参照できるようになるものです。

会社の各クライアントに機能更新プログラムがどこまでインストールされているか把握する場合、今までだったら資産管理ソフトウェアなどをクライアントにインストールして把握していたと思いますが、Windows Analyticsでは

・スクリプトを実行するだけで簡単に始められる
・クラウドベースで管理
・コストがかからない

というメリットがあります。
手軽に始められますので、ぜひチャレンジしてみてください。

SCCMトレーニングの現状と今後について ~ 2019年1月現在の話

$
0
0

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

Windows 10の更新プログラムを効率よく展開したいというニーズから、ここ数年SCCMの人気が再燃しています。
私が担当するトレーニング(コースID #23696)でも多くの受講者に来ていただいておりました。しかし、SCCMは年に数回のアップデートを繰り返すため、トレーニングで扱う内容も古くなってしまい、一時的に提供を中止しています。

SCCM 1702をベースにしたMS公式のSCCMトレーニングが現在、米国で提供開始しており、それが2019年上半期には日本でも提供開始される予定ですので、明確になりましたら、改めてご紹介させていただきます。SCCM 1702って、それでも古いよ!ってツッコミもあるかと思いますが、ちゃんとトレーニングの中では最新のバージョンまでカバーしますので、ご安心ください。

また、取り急ぎ何かトレーニングを受けたいという方は現在、

eラーニング形態ではLinkedInラーニングのSCCM基本講座を提供しておりますので、そちらをご利用いただければと思いますし、またハンズオン形式のものをお望みであれば、気軽にご相談いただければと思います。

ADFSからAzure ADへシングルサインオン環境を移行

$
0
0

image

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

一時期、Office 365へのサインインの50%はADFS経由と言われるぐらい、Office 365のサインインにはシングルサインオン(SSO)環境を構築し、運用している会社がたくさんあるかと思います。しかし、最近ではADFSでできる大抵のことはAzure ADでもできるようになっており、Azure AD Connectを使えばシームレスSSOもサポートされるので、いよいよサーバーレスで移行しようという話がちらほら出てくるようになりました。
(クラウド!って言っている時代にADFS2台+WAP2台の構成は..)

そこで今日はADFSからAzure ADへSSO環境を移行する方法を紹介しましょう、って書こうと思ったら既にAzure ADへの移行に関するドキュメントが色々と出ていました。

■Resources for migrating applications to Azure Active Directory
https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/migration-resources

■ADFS廃止のすすめ (移行手順が分かりやすく書いてあるのでおすすめ!)
https://github.com/teppeiy/AzureAD-Tips/blob/master/ADFS/Goodbye-ADFS.md

基本的にはここに書いてある手順を参考していただければと思うのですが、
ADFSサーバーのパラメーターシートをもとに各設定をAzure ADに移行しようと思ったら、何をどこへ移行するべきなのか?というところで迷子になるのではないかと思います。
ですので、今回はその辺りを整理してみました。

項目名 ADFSの設定項目 Azure ADの設定項目
フェデレーションサービス名 ADFSサーバーのプロパティ Azure ADで定義されるもので、自由に変更できない
IdPまたはCP 要求プロバイダー信頼 Azure ADそのものが[要求プロバイダー信頼]に相当するが、[要求プロバイダー信頼]レベルでのクレームルールのカスタマイズは不可
(というか必要ない)
RPまたはSP 証明書利用者信頼 [エンタープライズアプリケーション]または[アプリの登録]
クレームの定義 発行要求規則 [エンタプライズアプリケーション]-[シングルサインオン]
アクセス制御 発行承認規則 または
アクセス制御ポリシー
条件付きアクセス
証明書認証 あり
[認証方法]でプライマリ認証に証明書認証を選択
パスワードレス認証によって、結果的に証明書ベースの認証が利用可能
デバイス認証 あり
[認証方法]でプライマリ認証にデバイス認証を選択
条件付きアクセス
フェデレーションメタデータ https://フェデレーションサービス名/federationmetadata/2007-06/federationmetadata.xml https://login.windows.net/azure adドメイン名/federationmetadata/2007-06/federationmetadata.xml
サードパーティのデータストアからクレームを生成 [属性ストア]でSQL Serverなどを定義 ない
Azure AD Connectなどで事前にAzure ADに必要な属性は同期/インポートさせておく
SSOに関わる証明書 ADFSサーバーに
・通信用証明書
・トークン署名証明書
等を実装
(有効期限は自由に設定可能)
Azure ADで用意される証明書を利用 (有効期限3年)
エンドポイントのカスタマイズ [エンドポイント]項目で有効・無効化が可能 不可
ユーザー定義のクレーム [要求記述]で定義 extentionAttribute1などAzure ADで余っている属性を利用する??
アカウントロックアウト http://azuread.net/2014/06/05/adfsプロキシ経由のアクセスをロックアウト/ [認証方法]
スマートロックアウト
ログ イベントビューアから参照 Azure ADのサインインログ
・ただし、トークンに含まれるクレームの内容を参照することはできない
バックアップ あり
スクリプトを実行
自動的な方法はなく、
Azure AD PowerShellを使ってAzure ADのパラメーターをエクスポート/インポートする
(どうしてもやりたい場合)
サービスアカウント イベントビューアから参照 不要
Webアプリケーションプロキシ サーバーマネージャーから役割を追加 不要

※ざっくり書いたので間違ってたら、ご指摘いただけるとありがたいです。

こうやってみてみると、だいたいADFSにあるものはAzure ADにもあり、[属性ストア]のカスタマイズができないなど、ほとんどの人にとって無くても困らない?機能しか、ADFSには残されていなかったりします。
ただ、ADFSとAzure ADで機能的には同じでも、アーキテクチャが大きく異なるものがあるので、その点については次回以降で触れていきます。

条件付きアクセスの設定

$
0
0

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

以前、ADFSからAzure ADへの移行の話をしましたが、そのときに発行承認規則のクレームルールと条件付きアクセスはアーキテクチャが大きく異なるという話をしました。
そのため、ADFSのパラメーターシートを用意しても条件付きアクセスで何を設定すればよいのか?という課題があったかと思います。

そこで、今日は条件付きアクセスの設定例をいくつか紹介し、クレームルール時代にやっていたことをどうやって実現するか考えてみたいと思います。

その1:特定のグループにのみアクセス許可を与える

ADFS時代には発行承認規則から設定していたルールですが、条件付きアクセスでは超簡単!というか条件付きアクセスを使う必要はありません。
エンタープライズアプリケーションに登録されたアプリに対するアクセス許可設定(エンタープライズアプリケーション内の[ユーザー/グループ]から設定)を使います。

image

その2:特定の属性値を持つユーザーにのみアクセス許可を与える

部署が営業部だったら..」みたいな設定もADFS時代には発行承認規則からクレームルールを使って設定していたルールですが、この設定、条件付きアクセスには該当する項目がありません。そのため、少し工夫してグループのメンバーシップで解決しましょう。
Azure ADにはグループの設定に「動的ユーザー」というのがあり、これを利用すると特定の属性値を持つユーザーだけをグループのメンバーにできます。ですので、動的ユーザーでメンバーを定義しておき、その1で紹介した方法でグループに対してアクセス許可を与えればその2の条件が設定できるでしょう。
ちなみに下の図はEU加盟国に所属する国のユーザーという条件を設定しています。

image

その3:特定のOSを利用するユーザーにのみアクセス許可を与える

クレームルールではHTTPヘッダーのUser-Agentを参照し、その値をベースにアクセス制御することができましたが、同様のことは条件付きアクセスでも可能です。
条件付きアクセスポリシーの[条件]-[デバイスプラットフォーム]からOSを選択します。ちなみに条件付きアクセスでは単純に許可するルールは作れません(MFAを有効などの追加条件が入ったときだけ許可するルールは作れる)。そのため、拒否するルールを作る前提でここの部分の設定をしなければなりません。
それを踏まえてiOSを利用する場合のみアクセス許可を与えるという設定をする場合、[対象]にiOSを選択するのでなく、[対象外]にiOSを選択しておきます。
そうすると、iOS以外のOSは拒否する = iOSを許可するというルールが出来上がります。

image

その4:特定のOSバージョンを利用するユーザーにのみアクセス許可を与える

条件付きアクセスでは、OS種類を条件に設定できてもOSバージョンは条件に入れられません。ですので、Intuneと組み合わせて設定します。
まず、条件付きアクセスでは条件を設定せず、[アクセス権の付与]-[デバイスは準拠しているとしてマーク済みである必要があります]だけ設定しておきます。そうすると、Intuneの条件に合致した場合にアクセス許可を与えることになります(この文章、わかりにくいから変えてほしいんですよね。。)。

image

一方、Intune側では[デバイスのポリシー準拠]-[ポリシー]から新しいポリシーを作り、

image

[プラットフォーム]からOS種類を選択し、OS種類にあったポリシーを定義します。
OSバージョンを設定する場合なら[設定]-[デバイスのプロパティ]-[最小OSバージョン]または[最大OSバージョン]を使います。
バージョン番号はcmd.exeを実行した時に表示されるバージョンの記述方式
(Windows 10 1809なら10.0.17763.253 )のように入力します。

image

その5:特定の場所からアクセスするユーザーにのみアクセス許可を与える

オフィスの中からアクセスしたときだけアクセス許可を与える」のような設定を行いたい場合、ADFSサーバーでは発行承認規則で会社から外に出ていくときのIPアドレスで制御したり、Webアプリケーションプロキシを経由した/しないでアクセス制御していましたが、
条件付きアクセスでは[条件]-[場所]を使って会社から外に出ていくときのIPアドレスベースでアクセス許可を与えます。

image

[場所]で定義するIPアドレスはあらかじめ条件付きアクセスの[名前付きの場所]から定義します。場所の定義はIPアドレス/サブネットまたは国または地域で定義できます。
ただし、IPアドレスの指定はグローバルIPのみであり、プライベートIPを指定できない点がADFSのクレームルールとの違いです。

image

その6:ブラウザー種類に基づいてアクセス許可を与える

現時点では無理です。
クレームルールでは、User-Agentに含まれる文字列に基づいてアクセス許可を設定できるので「Firefoxのみ許可する」とかできたんですけどね。
ちなみに条件付きアクセスでは[条件]-[クライアントアプリ]からブラウザーorブラウザー以外の定義は可能です。

その7:事前に登録されたデバイスからアクセスした場合のみアクセス許可を与える

ADFSの場合、ADFSのデバイス登録サービスを通じてActive Directoryにデバイスを登録し、登録されたデバイスからアクセスしたときだけアクセスを許可という方法でこの条件を設定していました。
それに対して、Azure ADの場合、思いつく限りでは次の2つの方法があります。

■Active DirectoryのGPOからAzure ADにデバイスを登録するように設定し、Azure ADに登録されたデバイスからのみアクセス許可を与える
このやり方は別のブログ記事で紹介しているので、そちらを参考にしてください。
■Microsoft Intuneに登録しているデバイスからのみアクセス許可を与える
このやり方はその4の方法です。ポリシーを作っておいて、なんのルールも設定しなければ、Intuneに登録しているデバイス全部がアクセス許可を与えられることになります。

なお、ADFSのときにはコンピューターのSIDを指定して、特定のコンピューターからアクセスした場合のみアクセスを許可という設定が可能でしたが、Azure ADではそれはできません。

その8:社外からアクセスするときだけ多要素認証を要求する

社外からVPNで接続するときもそうであったように、社外からアクセスするときは追加のセキュリティを実装したいというニーズはあると思います。そのときに多要素認証を実装したいということであれば、
■[条件]-[場所]を使って「場所=会社から外に出ていくときのIPアドレス」を設定
■アクセス制御設定を使って、[アクセス権の付与]と[多要素認証を要求する]を設定

image

以上のように設定すれば、要件に合ったアクセス制御が可能になります。

■ ■ ■

いかがでしたでしょうか?
思いつく限りで書いてみましたが
こんなルールを作りたいとか
ADFS時代にはこんなことをしていたけどAzure ADではどう?
とかあれば、いつでもご意見などお寄せください。

Azure AD Connectの同期を自動で実行しない方法

$
0
0

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

今日は小ネタです。
「Azure AD Connectで同期条件を設定し、一部ユーザーだけを同期させたい」
こうしたニーズはよく伺います。この場合、Synchronization ServiceまたはSynchronization Rules Editorを使って同期条件を設定しますが、これらのツールはAzure AD Connectをインストールしてからでないと使えません。しかし、Azure AD Connectをインストールすると、同期が勝手に始まってしまう。

そんな方のためにAzure AD Connectをインストールするけど、同期は後からはじめる方法を紹介します。

Azure AD Connectのインストール時に同期は開始しない設定

これは簡単で、Azure AD Connectのインストールウィザードの最後の画面で、[構成が完了したら、同期プロセスを開始する]のチェックを外すだけです。そうすれば、同期を行わないでインストールだけ行うことができます。

手動で同期を開始する設定

手動で同期を開始するときはPowerShellのコマンドレットで、Start-ADSyncSyncCycleを使います。初回実行時はフル同期をするので、

Start-ADSyncSyncCycle -PolicyType Initial

のように実行します。

ただし、Azure AD Connectのウィザードで同期するように設定しなかった場合は30分に一度の同期スケジュールが設定されていないので、初回同期は成功しても、そのあとの同期は自動で行ってくれません。
同期を自動で行ってくれるようになっているか、確認するときはGet-ADSyncSchedulerコマンドレットを使います。(SyncCycleEnabled項目参照)

自動同期を有効にするには、このコマンドレットを実行します。

Set-ADSyncScheduler -SyncCycleEnabled $True

もう一度、Get-ADSyncSyncSchedulerコマンドレットを実行すると、SyncCycleEnabledコマンドレットが有効になっていることがわかります。

あとは放っておけば、勝手に30分に一度同期するようになります。


ついに登場!SCCM 5daysトレーニング

$
0
0

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

色々な方からご要望のあった、System Center Configuration Manager (SCCM) の5日間トレーニングがトレノケートさんから提供されることになりました!

Administering System Center Configuration Manager (#20703-1)
https://www.trainocate.co.jp/reference/course_details.aspx?code=MSC0652V

開催スケジュールでは2019年4月22日から26日の開催だけが発表されていますが、
今後も四半期ごとぐらいには提供されると思いますので、ご興味があればご覧になってみてください。

よくWindows 10の更新プログラム管理だけ教えてくれればいいよ、という方がいらっしゃいます。しかし更新プログラムを展開するには、誰に対して展開するのかを「コレクション」を指定して設定するけどコレクションって何?とか、なかなかインストールされないけどトラブルシューティングって何を見るの?とか、付随して覚えなければならないことがたくさんあります。ですので、更新プログラム管理に関連するテクノロジーや合わせて使いたいテクノロジーをまとめて紹介しますので、5日間って長いですけど、お付き合いください。

 

 

Azure ADにおけるOAuthの承諾設定

$
0
0

先日、ゾーホージャパンさんに寄稿させていただいている連載の中で、PaaS型クラウドサービスとAzure ADの関連付けについて解説させていただきました。その中でOAuth2.0プロトコルを利用している場合は、アクセス許可は管理者が設定するものではなく、アクセスするユーザー自身で設定するという話をしました。

アクセス許可を持っていないユーザーがOAuth 2.0を利用したクラウドアプリへのアクセスしようとすると、アクセス許可を割り当てる画面が表示され、[承諾]ボタンをクリックすると、Azure ADで承諾ボタンをクリックしたユーザーに対してアクセス許可が自動的に割り当てられるようになります。
(ちなみに、この操作を英語で”consent”と呼んでいますが、日本語だと何が正しいのかな?ここではとりあえず「承諾」と呼びます)

AAD8-5

ここからが今日の本題ですが、先日ご質問で

「管理者がアクセス許可を割り当てるようにコントロールできないですか?」

といただきました。
設定はAzure管理ポータルのAzure AD/エンタープライズアプリケーションから特定のクラウドアプリの設定画面を開き、プロパティを開くと[ユーザーの割り当てが必要ですか]という設定を見つけることができます。
ここで、設定を[はい]にすると明示的にアクセス許可が割り当てられていない限り、アクセスできないように構成できます。

image

一方、クラウドアプリごとに設定するのが面倒だということであれば、
Azure AD/エンタープライズアプリケーションのプロパティから
[ユーザーはアプリが自身の代わりに会社のデータにアクセスすることを許可できます]欄を[いいえ]に設定すれば、すべてのアプリでアクセス許可を割り当てない限り、アクセスできなくなります。

image

実際に上記の設定を行ったうえでアクセス許可が割り当てられていないユーザーがアクセスしようとすると以下のような画面とともにアクセスがブロックされます。

image

Azure AD全体管理者への不正アクセス

$
0
0

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

Office 365を利用する会社が増えてくるにつれ、Azure ADへの不正アクセスの試みも増えてくると思います。実際、Azure ADの全体管理者の権限を持つユーザーが不正に使われたという話もあると聞きます。

そこで今回は、どうやってAzure AD全体管理者のアカウントを特定し、不正アクセスしようとしているのかを考えてみたいと思います。

攻撃対象の会社がOffice 365/Azure ADを使っているか?

まず、会社のドメイン名はWebサイトや従業員のメールアドレスを確認すれば、xxxxx.co.jp のようなドメイン名を確認できると思います。
ドメイン名を確認できたら、コマンドプロンプトで「nslookup」コマンドを使うことで、Office 365を使っているかは簡単に確認できます。

下の図はnslookupコマンドを使って、microsoft.com ドメインのMXレコードを調べた様子ですが、mail.protection.outlook.com となっていることがわかります。

image

mail.protection.outlook.com というのはExchange Online Protectionで使われるFQDNなので、これが入っていれば、Office 365を使っていることがわかります。

じゃあ、Azure ADだけ使っていて、Office 365を使っていない会社の場合は?という疑問もありますが、これも簡単に調べられます。
Azure ADのユーザー向けポータルサイト(https://myapps.microsoft.com/)にアクセスして、user@xxxxx.co.jp のような適当なユーザー名+その会社のドメイン名でサインインを試みればよいのです。

imageimage

上の画面は左がドメイン名がAzure ADに登録されていない場合、
右がドメイン名がAzure ADに登録されている場合です。
(admin@sophianetwork.co.jpの名前のユーザー名は実在しませんが、ドメイン名自体が登録されていればパスワード入力の画面に推移してしまいます)

xxxxx.onmicrosoft.comを特定する

Office 365/Azure ADでxxxxx.co.jpのようなドメイン名は最初から設定することはできず、デフォルトでは必ずxxxxx.onmicrosoft.com のようなドメイン名を設定することになります。つまり、Azure ADを利用している会社ではxxxxx.onmirosoft.comドメインとxxxxx.co.jpドメインの2つのドメインが登録されている状態になっていて、ユーザーを作成するときにはどちらかのドメインを使って作成することになります。
一般のユーザーであればuser@xxxxx.co.jp のような名前になりますが、管理者アカウントの場合、SSO系のトラブル時にサインインできなくなることを避けるため、user@xxxxx.onmicrosoft.com を設定することが多くなります。そこで、それぞれの会社が利用しているxxxxx.onmicrosoft.comドメインを調べたいとなります。
これも調べる方法があり、差し障りのないところで話をすると、Office 365を利用しているユーザーからメールを送ってきてもらえば、メールヘッダにxxxxx.onmicrosoft.com が書いてあります。
以下は実際に受信したメールからメールヘッダの一部を取り出したところですが、

Authentication-Results: spf=pass (sender IP is x.x.x.x)
smtp.mailfrom=xxxxx.co.jp; yyyyy.co.jp; dkim=pass (signature was
verified) header.d=xxxxx.onmicrosoft.com;yyyyy.co.jp;

見事にonmicrosoft.comドメインの名前が書いてあることがわかります。

全体管理者を特定する

ここまで来たら、あとは推測です。
管理者のアカウントと言えば、

admin@xxxxx.onmicrosoft.com
administrator@xxxxx.onmicrosoft.com
root@xxxxx.onmicrosoft.com

のような名前が使われるのでは?と推測されるので、これらのアカウントを使ってパスワードを当たっていくわけです。

対策

以上を踏まえての対策ですが、

管理者とわかるユーザー名を設定しない

これに尽きると思います。

もちろん、多要素認証を設定する、複雑なパスワードを設定する、Azure AD PIMで管理者権限を限定するなどの基本的な対策もありますが、そもそも管理者ユーザーが誰であるかについて、的を絞らせないことで不正アクセスの可能性をぐっと下げることができるのではないでしょうか。

Intuneを利用したWindows Defenderウイルス対策の管理

$
0
0

皆さんこんにちは。国井です。
ウイルス対策ソフトって使ってますか?
以前だったら、こんな質問すれば「〇〇使ってます」って答えが明確に帰ってきていたと思います。なぜなら、自分でインストールしたから。
でも、Windows 10ではウイルス対策ソフトとして、Windows Defenderウイルス対策が搭載されているので、インストールするって機会もなくなってしまいましたよね(他社製品を使わない限り)。
だけど、他社製品と同等かといわれると、それは違うと思います。
シマンテックのウイルス対策で言えば、ノートンを買って入れているような状態で、
会社で一元的な管理をするSEP (Symantec Endpoint Protection) のようなものとは管理形態が全然違うわけです。

そこで、今日はMicrosoft Intuneを利用してWindows Defenderウイルス対策の一元管理が他社製品のようにできないか、考察してみたいと思います。

Windows Defenderウイルス対策の初期設定

一般的なウイルス対策ソフトなら、各PCへのインストールが必要になるけど、
Windows 10の場合は最初から実装されているので、インストールは要らないですね。
当たり前のことなんだけど、なんかうれしい。

スキャンスケジュールの設定

定期的なスキャンやリアルタイムスキャンの有効化などはIntuneのプロファイルから、まとめて設定できます。
Intuneのプロファイルは、デバイス構成 > プロファイルから Windows 10 – デバイスの制限 のプロファイルを作成すると、Windows Defenderウイルス対策に関するプロファイル項目が利用できるようになります。

image

Windows Defenderウイルス対策のプロファイル項目で、スキャンのスケジュールを設定します。
下の画面では、クイックスキャンは毎日お昼(12:00)になったら、フルスキャンは金曜日の18:00にそれぞれ実行するような設定にしています。

image

よくご質問でいただくのが、設定したスケジュールにPCの電源が入っていなかったらどうなるの?というのがありますが、Windows Defenderウイルス対策では「キャッチアップスキャン」と呼ばれる設定により、次回PCが起動したタイミングで「まだ行っていないスケジュールスキャン」をさかのぼって実行します。ちなみにキャッチアップスキャンもプロファイルで無効化できます。

スキャン設定の変更不可設定

Microsoft Intuneのプロファイルから展開された設定は強制されるため、ユーザーが手動で設定変更することはできません。これにより「ウイルス対策ソフト重たいなあ、そしたら機能を停止させちゃえ!」ということもできなくなります。
プロファイル設定はIntuneから設定を配布するだけでなく、設定を強制する効果があるので、プロファイルで設定すればユーザーが設定を変えることはできません。
同じ理由で[リアルタイム監視]を有効にしておけば、リアルタイムスキャンの設定も変えられないようにできます。

image

上の画面では、リアルタイム監視の有効化に加えて、DNSサーバーにレコードを書き込むなどの怪しい動きを監視する[動作の監視]やダウンロードコンテンツをリアルタイムスキャンする[すべてのダウンロードをスキャンする]も一緒に有効にしています。

定義ファイルの更新

ウイルス定義ファイル(トレンドマイクロ的に言うとパターンファイル)はWindows Updateを実行して入手します。既定では、各自のPCから[Windows Defenderセキュリティセンター]を開いて、[更新プログラムのチェック]をクリックして定義ファイルを入手しますが、

image
これを今すぐ実行したい場合、PowerShellの「Update-MpSignature」コマンドレットをクライアントコンピューターで実行します。
これを使ってIntuneから一元的に管理するのであれば、デバイス構成 > PowerShell スクリプトの設定項目からPowerShellコマンドレットが含まれるスクリプトを追加すれば、クライアントコンピューター上で1日1回自動的にウイルス定義ファイルを取得しに行くように設定できます。(1日1回のタイミングはIntuneの設定で変えられません…)

ちなみに、定義ファイルはWindows Updateの機能を使って取得します。ただし、定義ファイルは品質更新プログラムでも、機能更新プログラムでもないので、IntuneからWindows Update for Businessポリシーの設定を使って更新をコントロールすることはできません。

マルウェア検出時の対応

マルウェアを発見した時にはWindows Defenderウイルス対策であらかじめ設定されている処理方法に基づき、対応をしてくれます。設定をIntuneから変更する場合、
デバイス構成 > プロファイル > Windows 10 – デバイスの制限 > Windows Defenderウイルス対策から[検出されたマルウェアの脅威に対するアクション]で設定します。

image

検疫されたコンテンツの処理

マルウェア検出時の対応で検疫を選択した場合、マルウェアはローカルのコンピューターに実行できない状態にファイルを変換し、保存します。保存されたファイルに対する操作はローカルから行う必要があるので、Intuneの出る幕ではないですね。

マルウェア検出時の管理者への通知・レポート

マルウェアスキャン結果はIntuneのレポートにあったと記憶しているのですが、ないんですよね。Intune PowerShellにもなかったので。

アウトブレイク対応

「今すぐマルウェアスキャンしなさい」という命令をアウトブレイク対応という言葉で表現していますが、これもIntuneからはできない操作です。

■ ■ ■

こうやって見てみると色々足りない機能もありますが、これからの動向をウォッチしながらIntuneの機能が充実していくのを待ちたいと思います。

GoogleアカウントでAzure ADにサインイン

$
0
0

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

今さらな話かもしれませんが、備忘録として載せておきます。
Azure ADに登録されたアプリへのアクセス許可は基本的にアプリが登録されたAzure ADディレクトリ内のユーザーまたはグループに対してしか割り当てることができません。しかし、アプリへのアクセス許可を自分の会社のユーザー以外にも割り当てたいというニーズはあると思います。そのような時に利用するのがAzure AD B2Bの機能になりますが、Azure AD B2Bも相手の会社がAzure ADを利用していることが前提となります。では、アクセス許可を与えたい相手がAzure ADを使っていない場合はどうすればよいでしょうか?
今回紹介するのは、Azure ADに関連付けられたアプリへのアクセス許可にGoogleユーザー(もちろんG SuiteもOK!)を割り当てたいというときの方法です。

■ ■ ■

Azure ADではAzure ADに関連付けられたアプリへのアクセス許可を割り当てるときに、(一部例外を除いて)次のユーザーに対する割り当てができます。

・自分のディレクトリ内のユーザー/グループ
・ゲストユーザーとして登録された他のAzure ADディレクトリのユーザー
(Azure AD B2B)

・Googleに登録されたユーザー
・GitHubに登録されたユーザー

もし、相手の会社のユーザーに対してアプリへのアクセス許可を割り当てたければ、相手の会社でAzure ADを使っていればAzure AD B2Bで登録されたユーザー、Googleを利用していればGoogleユーザーアカウントを使ってアクセス許可の割り当てを行います。

この仕組みはOAuth 2.0プロトコルを使った連携によって実現しており、
私たちがアプリにアクセスするときにAzure ADのサインイン画面でGoogleのユーザー名を入力すれば、Google IdPで認証を行うようにリダイレクトされます。これは、Azure AD B2BやGitHubのユーザーでサインインするときも同じ要領です。

image

そして、Google IdPでの認証が完了すると、認証が完了したことを示すトークンがAzure ADに送られてきて、自分の会社のAzure ADでアプリへのアクセス許可を検証します(ちなみにこの動きはAzure AD B2Bでも同様の連携を行います)。

もちろん、このような連携を行うためには事前にGoogleユーザーを管理するGoogle IdPとAzure ADの間での連携設定が必要になるので、ここではxxxxx@gmail.com ユーザーがGoogleで認証し、その結果に基づいてAzure ADに関連付けられたリソースにアクセスできるようになるために必要な設定を順番に紹介します。

Google IdP×Azure ADの連携設定

Googleユーザーにアプリへのアクセス許可を割り当てられるようにするために、やらなければならないことはGoogle IdPをAzure ADに登録することです。設定はAzure管理ポータルから[Azure Active Directory]-[組織の関係]から[IDプロバイダー]で行います。

image

このとき、Google IdPのクライアントIDとクライアントシークレットの情報が必要になるので、まず最初にGoogleに値を取りに行きます。
Google IdPのクライアントIDとクライアントシークレットはhttps://console.developers.google.comからとってきます。
gmailアカウントでログインし、[認証情報]から[認証情報を作成]-[OAuthクライアントID]をクリックして、

image

承認済みのJavaScript生成元に
https://login.microsoftonline.com

承認済みのリダイレクトURLに
https://login.microsoftonline.com/te/ディレクトリID/oauth2/authresp

と入力します。ちなみにディレクトリIDはAzure管理ポータルの[Azure Active Directory]-[プロパティ]から確認できます。

image

上記の設定が完了すると、クライアントIDとクライアントシークレットが生成されるので、

image

Azure管理ポータル画面の[Azure Active Directory]-[組織の関係]-[IDプロバイダー]に戻ってきて、[+Google]をクリックし、

image

Google IdP側で取得したクライアントIDとクライアントシークレットを登録します。

image

設定はこれだけ。
今回は、Azure App Serviceに作成したWebアプリにxxxx@gmail.comアカウントを登録してみました。(ちなみにAzure AD B2Bの場合は、事前に他のディレクトリのユーザーをゲストユーザーとして登録しておく必要がありますが、Googleユーザーの場合はいきなりアクセス許可を割り当てられます)

image

アクセス許可を割り当てるなどして、自分の会社のAzure ADディレクトリで使われているGoogleユーザーの一覧は[Azure Active Directory]-[組織の関係]から確認できます。

image

では、アクセスしてみましょう。アクセス許可が割り当てられたWebアプリのURLを入力すると、サインイン画面にリダイレクトされるので、
招待されたユーザーであるgmailアカウントを入力し、パスワードを入力すると、

image

OAuth2.0ではおなじみの画面(同意とか承諾って呼ばれる画面ですね)が出てきます。ここを承諾すると、

image

次に利用規約画面が登場します。ここで表示される利用条件は[Azure Active Directory]-[組織の関係]-[利用規約]で登録したドキュメントが表示されます。また、同意した場合、同意したユーザーの一覧が同じく[利用規約]画面で確認できます。

image

利用規約に同意すると、Webアプリにアクセスできました。

image

Google IdPとAzure ADの連携設定さえ行えば、ゲストユーザーの作成すら行うことなく、アクセス許可を割り当てるだけで、Googleユーザーがアプリにアクセスできるようになります。

また、今回はアプリにアクセス許可を割り当て、その上でアクセスできる様子を確認しましたが、アクセスパネル(https://myapps.microsoft.com/)経由でアクセスさせることも可能です。ただし、どこのテナントのアクセスパネルにアクセスするかを明確にしたURLを書いてアクセスするようにしてください。
(https://myapps.microsoft.com/?tenantid=テナントID という感じの書きかたですね)

ManageEngineアンバサダーに就任しました

$
0
0

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

このたび、ゾーホージャパンさんが提供するIT運用管理ソフトウェアである、ManageEngineのアンバサダーに就任することになりました。

https://www.manageengine.jp/news/news_20190513.html

image

ManageEngineには色々なプロダクトがありますが、中でもActive Directoryの運用管理に関わる管理製品を中心に情報発信を行い、それぞれの企業におけるActive Directoryの運用管理やAzure ADとの平行運用の部分を最適化するためのヒントを色々と提供できればと考えています。
ManageEngineはこれから多くの会社にとって使いやすくなると伺っているので、そのことをひとりでも多くの方に知っていただけるようにチャレンジしてみます。

様々な媒体で情報発信していきますが、その活動報告はこのブログの中でも定期的に行っていきますので、引き続きどうぞよろしくお願いいたします。

Azure ADへのデバイス登録とその効用

$
0
0

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

最近、Azure ADやIntuneのトレーニングの中でWindows 10のデバイス登録に関してご質問をいただくことがよくあります。「デバイス登録の意味が分からない」と。

Windows 10のデバイスをマイクロソフトのクラウドサービスに登録しようと思ったら、登録箇所には次の2つがあります。

・Azure AD
・Microsoft Intune

さらに、Azure ADへのデバイス登録には、次のような登録方法があるわけです。

・ デバイス登録
・ Azure AD参加
・ ハイブリッドAzure AD参加

こんな感じで、デバイス登録と言っても色々な登録箇所、登録方法があるわけで、一体どのようなときに、どれを使えば良いのかよくわからないということが訳わからなくなってしまっている理由のようです。

Microsoft Intuneにデバイスを登録するのは、デバイスをIntuneから管理したいから、というのはわかるのですが、

そもそも、なんでAzure ADにデバイスを登録する必要があるの?

という根本の疑問があると思います。ですので、今日はこの部分を私の勝手な解釈で、
このメリットがある!こう使え!というのを決めてしまいたいと思います。

では、Azure ADのデバイス登録の方法、3つについて順番に見ていきます。

Azure ADへのデバイス登録

Azure ADへのデバイス登録は単純にデバイス情報をAzure ADに登録するだけで、デバイスに対するインパクトが少ないので、BYODのシナリオでお勧めです、などと人は言います。しかし、そもそもなぜ、Azure ADにデバイス登録する必要があるかと言われれば、
それは

Microsoft Intuneに登録されているデバイスであることを条件に、
条件付きアクセスでアクセス許可させたいから。

条件付きアクセスで特定のユーザーがアプリにアクセスするときに、[デバイスは準拠しているとしてマーク済みである必要があります]にチェックをつけると、

image

次の3つの条件を満たしているときにアクセスを許可します。

・ Intuneにデバイスが登録されているか?
・ Azure ADにデバイスが登録されているか?
・ Intuneのコンプライアンスポリシーに準拠しているか?

このうち、2番目の条件の「Azure ADにデバイスが登録されているか?」を満たすためにデバイスをAzure ADに登録する必要があるのです。
ちなみに「Azure ADにデバイスが登録されているか?」の条件を満たすためには、Azure ADへのデバイス登録以外にも、後述するAzure AD参加、ハイブリッドAzure AD参加でもOKです。

Azure AD参加

Azure AD参加はWindowsのサインイン画面で、Azure ADユーザーアカウントを使ってサインインするため、ワークグループでWindows 10を利用するのとは明らかに違いがあります。
デバイスをWindows 10にAzure AD参加させると、次のようなサービスが一緒に利用できるようになります。簡単に言えば、これがメリットです。

image

この話は色々なところで出ている話でもあるので、このへんで話を終わらせておきます。

ハイブリッドAzure AD参加

「ハイブリッド」って、言葉の響きから、なんか凄いことができそうですよね。
だけど、私の勝手な解釈で言うなら、利用目的はただひとつ。

条件付きアクセスで、Active Directoryドメインに参加しているデバイスに対する
アクセス許可を与えたいから。

条件付きアクセスで「会社支給のデバイスからアクセスした時だけアクセスを許可したい」というニーズはよく聞く話です。
このとき、

Microsoft Intuneに登録されているデバイス = 会社支給のデバイス

という考え方があるのと同時に、

Active Directoryドメインに参加しているデバイス = 会社支給のデバイス

という考え方もあるでしょう。
Intuneに登録されているデバイスであれば前述の[デバイスは準拠しているとしてマーク済みである必要があります]を使いますが、ADドメインに参加しているデバイスの場合は[ハイブリッドAzure AD参加済みのデバイスが必要]を使って定義します。

image

というと、なんで[AD参加済みのデバイスが必要]ではなく、[ハイブリッドAzure AD参加済みのデバイスが必要]なの?
という疑問が出てくるでしょう。

これはAzure ADの立場で考えてみればわかると思います。

クライアントコンピューターが「オレ、AD参加のデバイスだけど」と言ってAzure ADにアクセスしても、Azure ADはそのことを確認する手段がありません。
だからこそ、Active DirectoryのコンピューターアカウントをAzure ADにも登録するハイブリッドAzure AD参加という機能が存在するのです。
設定方法についてはQiitaで紹介してくださっているので、ご一読されることをお勧めします。

【おまけ】Windows 10デバイス登録種類別管理先一覧

漢字がずらっと並ぶ、中国語的なタイトルになりましたが、Windows 10がどのようにAzure ADに登録されるかによって、どこから管理を受けるかが異なります。
最後に、以下の5つのパターンにおけるWindows 10のデバイス管理形態を紹介します。

image

Active Directoryドメイン参加

えーっ、今さらその話?!という声が聞こえてきそうですが、他との比較がしやすいように載せておきます。

image

Active Directoryにドメイン参加するかたちでデバイス情報を登録した場合、デバイス情報はActive Directoryにコンピューターアカウントとして登録されます。また、ドメイン参加すると、コンピューターの電源を入れたときに行うサインイン(Windowsサインイン)にもActive Directoryドメインのユーザー情報を使います。

それから登録したデバイスにはグループポリシーを通じてポリシーが割り当てられる特徴があります。

Azure ADデバイス登録

Azure ADに単純にデバイス情報を登録した場合、登録したアカウント情報はAzure ADのものを使いますが、Windowsサインインにはワークグループを引き続き使うことになります。また、Intuneにデバイスが登録されていればポリシー管理にIntuneを利用することになります。

image

Azure AD参加

Azure AD参加の場合はAzure ADデバイス登録する場合とは異なり、WindowsのサインインにAzure ADユーザーを使うことになります。

image

ハイブリッドAzure AD参加

ハイブリッドAzure AD参加の場合はActive Directoryドメイン参加している状態からAzure ADにデバイスを登録する機能ですから、WindowsサインインはActive Directory、ポリシー管理はグループポリシーとIntuneのハイブリッド(Intuneを利用している場合)になります。グループポリシーとIntune、どちらの設定が優先されるかについては別のブログ記事を投稿しましたので、そちらを参考にしてください。

image

ハイブリッドAzure AD参加 + SCCM登録

SCCMの共同管理と呼ばれる機能を使っている場合、ハイブリッドAzure AD参加しているデバイスがSCCMにもデバイスを登録することになりますが、この場合はポリシー管理がグループポリシー、Intune、SCCMの3重奏になります。ちゃんとポリシー管理しないと、もはや何が割り当てられるかわからない??

image

■ ■ ■

設定方法に関する説明などは書きませんでしたが、まずは概念を把握するのに役立てていただければと思います。

【参考】Azure Active Directory のデバイス管理とは
https://docs.microsoft.com/ja-jp/azure/active-directory/devices/overview


Office 365とクラウドサービスの認証ベストプラクティスコース再始動

$
0
0

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

2018年6月の開催を最後にお休みをいただいていた、Office 365とクラウドサービスの認証ベストプラクティスコースですが、このたびAzure AD完全対応版として、再リリースすることになりました。

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

これまで提供してきた「Office 365とクラウドサービスの認証ベストプラクティス」コースではADFSを扱ってきましたが、今回はAzure ADとクラウドサービスを関連付けてシングルサインオンする、Azure ADとオンプレミスActive Directoryを関連付けて一体運用する、という部分に特化したトレーニングコースを提供します。

対象となる方々

SIerにお勤めの方であるか、自社のIT部門を担当している方であるか、は明確に定めていませんが、インフラエンジニアとしてAzure ADをこれから導入したい、または導入しているのだけどクラウドサービス/アプリの関連付けの部分でどうするべきか?オンプレミスActive Directoryとの共存をどうするべきか?ということでお悩みの方を対象にしています。

取り上げる技術エリア

・Azure ADとクラウドサービス/アプリの関連付けによるSSOの実装
・オンプレミスActive DirectoryとAzure ADの一体運用

この2つに特化しています。
Azure ADという認証基盤を活用できるようになるには、やはり多くのアプリを関連付けておくことが欠かせません。だからこそ、Azure ADとクラウドサービスやアプリを関連付けるところに注力することにしました。ただし、アプリ開発のコースではないので、「アプリの調達基準にOpenID ConnectやOAuth 2.0を含める」としたアプリを開発してもらったときにインフラエンジニアとして、それをどうやってAzure ADに実装するか、また正常に運用させるか、というところに注力しています。ですから、アプリ開発を行った経験がなくても大歓迎です。

トレノケートさん開催のコースとの違い

私自身、トレノケートさんでもAzure ADのトレーニングコースを扱っておりますが、トレノケートさん開催のAzure Active Directoryを使用した認証基盤の構築コースではAzure AD全般を取り上げています。本コースではユーザー作成の部分などについて時間をかけて触れることができないので、その意味で内容的には少し異なる予定です。ですので、オーバービューから学習したいという方は、先にトレノケートさんのコースをご受講いただくとよいと思います。

敷居が高くないですか?

特定の分野に特化するということは、敷居が高いと思われるかもしれません。しかし、過去の開催でもそうでしたが、実際には受講される方が「私はテキストに書いてないけど、こういうことを知りたい」と言われることが多く、それに合わせてカスタマイズしていくスタイルで進めることが多いです。テキストの内容やレベル感よりも受講される方の要望を満たしていくということに重きをおいていますから、敷居が高いなどと言わずにご参加いただければ幸いです。

お申込み・会場について

前回と同様にイルミネート・ジャパンさんにお願いしました。Webサイトから日程も含めてご確認いただけます。
なお、イルミネート・ジャパンさんとの協業でAzure ADだけでなく、Microsoft 365に関わる様々な分野をピンポイントで学んでいただけるコースを提供する予定ですので、こちらも順次提供予定です。お楽しみに。

初回開催は2019年7月31日~8月2日です。
会場でお会いできることを楽しみにしています。

Office 365とクラウドサービスの認証ベストプラクティスコース紹介動画を作りました

$
0
0

皆さんこんにちは。国井です。
先日よりご案内させていただいている「Office 365とクラウドサービスの認証ベストプラクティス」コースですが、コースで扱う内容とその背景について紹介動画を作りました。

2019年7月より開始する、新しい「Office 365とクラウドサービスの認証ベストプラクティス」コースで扱う内容やコース開催の背景などを紹介いたします。お申し込みは https://www.illuminate-j.jp/training/detail/ci525-h よりどうぞ。
Office 365とクラウドサービスの認証ベストプラクティスコースのご紹介 - YouTube

動画の中で触れられなかったことをひとつだけ。
OpenID Connect / OAuth2.0とAzure ADの連携についてインフラエンジニアが知っておく必要があるか?という点です。
これから先、オンプレミスに展開したアプリをクラウド移行しようと考えたとき、認証をどうするか?という課題があります。これまでActive Directoryで認証していたケースであれば、Azure ADドメインサービスを使って、クラウドでもAD認証ができるようにしたり、またはAzure AD App Proxyを使ってアプリをオンプレミスに置いたままの状態でAzure AD経由でアクセスできるようにする方法もあるでしょう。
しかし、これらの解決策は一時しのぎに過ぎず、最終的にはオンプレミスにアプリを移行すると同時に、クラウドにあった認証方法を選択することになるはずです。
そうなると、恐らくOpenID Connect / OAuth2.0の一択です。

これからクラウドで動作する自社開発アプリを作ることになれば、OpenID Connect / OAuth2.0を使って認証することになるでしょうし、アプリの調達基準にOpenID Connect / OAuth2.0という文言が必ずや入ってくることでしょう。
そうなったときに開発者の方がアプリの中に実装してくれるからいいや、とは言ってられません。開発そのものを自分で行わないまでも、アプリの検収を行ったり、Azure ADとの連携部分では責任を持って取り組まなければならないですし、また運用フェーズに入ってからトラブルが起きれば、その対応もしなければなりません。

だからこそ、他のAzure AD研修では扱うことのないOpenID Connect / OAuth2.0を思い切って取り上げることにしたのです。

少し話が長くなりましたが(動画でも少し長くお話していますが)、コース受講の判断の助けになれば幸いです。

Microsoft Defender ATPでのクエリの使い方

$
0
0
皆さんこんにちは。国井です。
先日、あるトレーニングで「ユーザーのアクセスログを取りたければMicrosoft Defender ATP (MDATP) を使えば一発ですよ」などとお話しさせていただいたのですが、そもそもどうやってその見るの?という疑問があったかと思います。ということで、今日はMicrosoft 365 Enterprise E5などで利用可能なMicrosoft Defender ATP (MDATP) を使ってログを見る方法について紹介します。
MDATPはあらかじめWindows 10のコンピューターでMDATPから提供されるスクリプトを実行すると、自動的にWindows 10コンピューターの操作ログを収集し、クラウド経由でその内容を参照できるというもので、Windows 10コンピューターがマルウェア感染したり、不正アクセスに遭ったりしたときに、管理者がログを見てどういうインシデントがあったか?を調査する目的で使われるものです。ただ、既に何回か言葉として使っているように「操作ログ」が取れるので、インシデント対応だけでなく、他の目的にも使えるんですよ(悪用厳禁!)。
禁断のログをちょっと見てみましょう。

マシンごとに生成されるログ

MDATPのポータルサイト(https://securitycenter.windows.com)にアクセスし、管理者のアカウントでサインインします。
ポータルサイトにアクセスできたら、画面左側の[Machine list]から該当のコンピューターをクリックすると、タイムラインでコンピューターで行った操作が出てきます。
image
ここのログをクリックすると、その詳細も出てきます。例えば、下のログはMicrosoft Edgeを使ってyodobashi.comにアクセスしていることがわかりますね。
image

Advanced Huntingを使ったログに対するクエリ

ここまでいくつかのログを見てもらいましたが、でも一番見たいのは時系列に並んだログではなく、特定の操作を行ったユーザー/コンピューターがいるか?ということかもしれません。
その場合、MDATPの中に用意されているAdvanced Huntingを使ってクエリを書いてあげればよいでしょう。
MDATPの左側のメニューからAdvanced Huntingにアクセスし、クエリを書いていくだけで使えます。
クエリの書き方はサンプルを参考にするとわかりやすいと思います。サンプルは[Shared Queries]-[Suggested]から選択できるので、ここでは[Files with double extensions]という拡張子が2重になっているファイルが生成されたイベントを抽出するクエリを選択してみました。そうすると、なんとなく文法がわかってきますね。
image
書き方ですが、まず最初にクエリを投げる分野を選択します。例えば、ファイルが生成(実行)されたイベントであればProcessCreationEventを選択します。レジストリに対する操作であればRegistryEvents、ネットワークアクセスに関する操作であればNetworkCommunicationEvents、がそれぞれ用意されています。
次に|で区切ってクエリの条件を設定します。条件に何が使えるかは、一度条件を指定しないで実行してみればわかりやすいと思います。ただし、そのまま実行してしまうと大量な結果が返ってくるので、| top 10 by EventTime と追記しておきましょう。これで直近10個のログだけが表示されます。

ProcessCreationEvents
| top 10 by EventTime

結果はこんな感じ。

image

なるほど、FileNameに使われたファイルの名前が入るのか、ということがわかります。だから、二重拡張子のファイルを見つけるのであれば、

ProcessCreationEvents
| where FileName endswith ".pdf.exe"
| top 10 by EventTime

のように書けばよいのですね。さらに、whereでor条件を設定するのであれば、

| where FileName endswith “.pdf.exe”
or FileName endswith “.doc.exe”

のように書きます。そのほか、検索条件を7日前までに絞り込むなら

| where EventTime > ago(7d)

のように書きます。また、検索結果に表示される内容(列)を定義したい場合は

| project EventTime, ComputerName, FileName, AccountSid, AccountName, AccountDomain

のようにprojectで始まる項目で列名を定義してください。

【クエリ例】マルウェア検出の結果を参照する

以前のブログ投稿で、Windows Defenderウイルス対策で検出したマルウェアの情報は一元的に参照する方法は(Intuneに)ないという話をしましたが、MDATPを使えば各コンピューターで出力されたアラートは一元的に参照できます。
コンピューターで出力されたアラートにはAlertEventsを使います。
AlertEvents
| where Title startswith "Windows Defender AV detected"
| top 10 by EventTime

image

【クエリ例】特定ファイルへのアクセスを参照する

先日、私のコンピューターではF03F61A.docxという名前のファイルができていました。これって、マルウェアによって作られたの??などという心配があるなら、次のようなクエリで調べましょう。

FileCreationEvents  
| where FileName == "F03F61A.docx"

image
(どうやらテンポラリで作られたファイルなだけだったようです。)

【クエリ例】特定Webサイトへのアクセスを参照する

この間、軽い衝撃を受けたのは、Microsoft Cloud App Security(MCAS)を見ていたら、Exchange Onlineに非公開の予定を入れたのに、MCASのアクティビティログからはバッチリ見えてるのです!
image
(業務時間中に、こっそり整体に行こうとしているのがバレてる)
となると、MCASにアクセスした人を知りたいとなります。この場合、MCASのWebサイト(https://portal.cloudappsecurity.com/)にアクセスしたことを追跡したければ、私の秘密の予定を見ようとした(かもしれない)人を追跡できます。この場合、NetworkCommunicationEventsを使って次のようなクエリを書きます。
この書き方はGitHubに教わったものですが、最初の行に
let partialRemoteUrlToDetect = “任意のURLドメイン”と書けば、
| where EventTime > ago(7d)
and RemoteUrl has partialRemoteUrlToDetect

と指定することで、“任意のURLドメイン”の部分に書いたドメイン名がRemoteUrlに含まれるかチェックしてくれます。

let partialRemoteUrlToDetect = "portal.cloudappsecurity.com";
NetworkCommunicationEvents  
| where EventTime > ago(7d)
and RemoteUrl has partialRemoteUrlToDetect
| top 10 by EventTime

image

これを流用すれば、業務に関係ないWebサイトを見に行った人とか、そういうのも追跡できますね。繰り返しますけど、悪用厳禁でお願いします。

 

ハイブリッドAzure AD参加のトラブルシューティング

$
0
0

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

Azure ADに関連付けられたアプリにアクセスするときに、特定の条件を満たすユーザー/デバイスからのみアクセスを許可するようなアクセス制御機能に「条件付きアクセス」という機能があります。
条件付きアクセスでは、色々なアクセス制御のための条件を設定できますが、その中のひとつに「Active Directoryドメインに参加しているPCだけがアクセスを許可する」設定(項目名では[ハイブリッド Azure AD 参加済みのデバイスが必要])があります。
この設定を利用する場合、単純にActive Directoryドメインに参加していればよいわけではなく、Azure ADにActive Directoryドメインに参加しているPCの情報を登録しておく必要があります。これをハイブリッド Azure AD 参加と呼びます。

ハイブリッドAzure AD参加の設定方法についてはQiitaで紹介されているので、それを見ていただくとよいでしょう。

https://qiita.com/Shinya-Yamaguchi/items/73016fcdb5beeaefa5ba

ただ、ハイブリッドAzure AD参加って、いつ登録が始まっているのか、よくわからないし、登録が完了したのかもよくわかりません。そこで、登録が完了したのか?また、登録に失敗しているのであれば何が原因なのかを探る方法についてまとめておきたいと思います。

登録状況の確認

ハイブリッドAzure AD参加の登録状況はクラウド側とクライアント側で確認する方法があります。
まずクラウド側はAzure AD管理ポータル(https://aad.portal.azure.com)の[Azure Active Directory]-[デバイス]-[すべてのデバイス]から確認できます。

image

一方、クライアント側はコマンドプロンプトから「dscmdreg /status」コマンドを実行すると確認できます。

image

トラブルシューティング(クライアント側)

ハイブリッドAzure AD参加を行うためのデバイスの登録はグループポリシーが適用されたタイミングで行う(よう)ですが、それがうまくいかないとこんな感じになります。

image

さらに実行結果をスクロールすると、こんな情報が..

image

[Diagnostic Data]欄では0x801c03f2というエラーコードが生成されているので、これを手掛かりに調査を進めていくのもよいでしょう。
さらに別の視点から見てみよう!ということで、イベントビューアを使います。
イベントビューアでは、[アプリケーションとサービスログ]-[Microsoft]-[Windows]-[User Device Registration]項目からデバイス登録に関する情報を参照できます。

image

イベントID204, 304, 360 というあたりのログが生成されているのがわかります。詳細を見てみると

image

image

204と304のエラーログを見ると、device object by given id is not foundというdirectory errorなので、ディレクトリ(Azure AD)側にデバイスオブジェクトがないということを言っているのがわかります。

image

さらに360のログを見ると、WHfBのためのハードウェア要件やプロビジョニング処理のための要件に問題はないことがわかるので、類推するにクライアント側の問題ではなく、サーバー側の問題ではないだろうか?ということがわかります。

トラブルシューティング(サーバー側)

サーバー側で見るべきポイントは、グループポリシーの設定が正しいものであるか?
それからDNSレコードの設定が正しいものであるか?
という設定ミス系をまずは確認しておきましょう。
その他のポイントとしては、Azure AD Connectの同期。
Azure AD Connectの同期ではActive Directoryドメインに登録されたデバイス情報がAzure ADに同期されることによって、デバイス情報が事前登録され、そしてクライアントからのデバイス登録要求があると、事前登録されたデバイス情報と突き合わせをし、正しければ登録完了となります。

しかし、Azure AD管理ポータルでは事前登録されたデバイスの情報は見えないので、Azure AD Connectのツールを使って同期が行われたかを確認します。
Azure AD Connectをインストールすると一緒にインストールされるツールである[Synchronization Service]ツールを起動し、[Metaverse Search]タブを開いて、[device]オブジェクトを検索します。

image

すると、検索結果はゼロ!
なるほど、さっきエラーログでdevice object by given id is not foundと出てきたのはAzure AD Connectでデバイス情報が同期されていなかったからなのか!ということがわかります。
デバイス情報が同期されていない場合は、OU単位で同期対象をフィルタする設定で除外されていることが考えられます。
Azure AD Connect ツールを起動し、[同期オプションのカスタマイズ]を選択して、

image

デバイスオブジェクトが含まれるComputers OUが同期対象になるようにカスタマイズしておきましょう。

image

設定できたら、同期を実行します。同期は差分同期ではなく、フル同期する必要があるので、

Start-ADSyncSyncCycle –Policytype Initial

を実行してください。

フィナーレ

同期が完了したら、もう一度クライアントコンピューターでグループポリシーを適用し、デバイス登録を再実行します。
すると、今度はデバイス登録できたことがわかります。

image

image

その他、デバイス登録時にどのような通信を行うのか?やプロキシを利用しているケースは?などのトラブルシューティング上の切り分けもあるかと思いますが、MSさんでとても良い資料を出してくださっているので、これはお勧めです!

https://github.com/yusukekodama/PMActivities/blob/master/Webinar/Schedule.md

今回はハイブリッドAzure AD参加のトラブルシューティングについて紹介しましたが、そもそもハイブリッドAzure AD参加って何?という基本から改めて体系的に学びたいという方にはトレーニングコースも用意させていただいておりますので、あわせてご検討ください。

ブログ始めて10年になりました。

$
0
0

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

人から言われて気が付いたのですが、
このブログ、2019年6月25日で10年を迎えていました。
(10年で445個の投稿があったそうです)

TechEdというマイクロソフトさんのイベントでForefront Identity Manager(FIM)という製品の話をする機会があったのですが、そのときに時間内に話しきれない内容をまとめて提供するというのが、このブログの始まりでした。その後、FIMは廉価版としてAzure AD Connectとなって提供されるようになり、その前の年(だったかな)のTechEdのイベントでお話しさせていただいたADFS 1.2は、その後ADFS2.0になり、Office 365との組み合わせで大ヒットしましたね。

現在のAzure ADを支えるテクノロジーを早い段階から扱わせてもらったことは本当にラッキーとしか言いようがないのですが、早い段階から触れることによって得た多くの経験や情報をできるだけわかりやすく言語化して、多くの人に情報を共有するということにこれからも努めていこうと思います。

これからもよろしくお願いいたします。

Viewing all 433 articles
Browse latest View live