皆さんこんにちは。国井です。
SCCM1710に対応した評価ガイドがマイクロソフトさんのWebサイトよりリリースされました。今回リリースされたのは、

■System Center Configuration Manager (CB) 評価ガイド 機能紹介とアーキテクチャ編
http://download.microsoft.com/download/F/0/D/F0D20D4C-B594-4341-924C-55DFF50FED88/SCCM_Architect_EvalGuide_jp.docx
■Office 365ProPlus編
http://download.microsoft.com/download/F/0/D/F0D20D4C-B594-4341-924C-55DFF50FED88/SCCM_EvalGuide_O365ProPlus_jp.docx
■Windows 10管理編
http://download.microsoft.com/download/F/0/D/F0D20D4C-B594-4341-924C-55DFF50FED88/SCCM_EvalGuide_Win10_Management_jp.docx

の3つで、それぞれVersion 2として提供されています。
(ちなみに基本環境構築編もv1.1となっていますね)

Windows 7のサポート期限が切れるからなのか、Windows 10の更新プログラム管理が大変だからなのか、よくわからないけど、最近SCCMのお問い合わせは本当に多く、
オンプレミスの製品にバイバイって言う日が来るのはだいぶ先のように思っています。

皆さんこんにちは。国井です。
今日はWindows Server 2016のADFSサーバーの証明書認証についてです。

Windows Server 2016のADFSサーバーは外部アクセスでも、証明書のみで認証を済ませることができるとあって、前のバージョンからの移行を行うモチベーションになっていたりします。
さらに、Windows Server 2016のADFSサーバーの証明書認証では、TCP443で通信できるようになっており(これまではTCP49443を使って通信していた)、この点では大きなメリットがあります。

設定方法については、最近ADFS/Azure AD絡みの投稿をいっぱい書いてくださっているMiyaさんのサイトで紹介されています。

https://miya1beginner.com/windows-server-2016-adfs-sans-binding

本題ですが、TCP49443からTCP443に切り替えた時に、今まで行っていた証明書認証ができなくなるというご質問をいただいたので、その解決方法を紹介します。

基本的には上記のサイトで紹介されている手順を踏めば、それで必要な設定はすべて揃ったことになるのですが、証明書の入れ替えを前に行っていたりすると、スムーズに証明書認証の設定変更ができていないことがあるのです。
ADFSでは、http.sysのバインド設定で証明書とホスト名(FQDN)、それからポート番号をマッピングさせ、管理しているのですが、そのバインド設定が正しくないときがあるのです。
確認するときはコマンドプロンプトで「netsh http show sslcert」と入力すると、

こんな感じでホスト名、ポート番号、証明書の組み合わせが確認できます。
今見てもらっている組み合わせの中でチェックするポイントは、Miyaさんのブログの中にもありましたが、適切な証明書が割り当てられているか？そして、ポート番号443だけが使われるように構成されているか？という点です(私の知る限りでは)。

それを踏まえて、もう一度、上の画面を見てみると、ポート番号49443のマッピングが残されていることがわかります。ですので、これを削除しましょう。
削除するときは「netsh http delete sslcert hostnameport=sts.xxx.adfs.jp:49443」という感じで入力したうえで、もう一度「netsh http show sslcert」を実行すれば、

ほら、消えました。
この状態でサインインを試してみると、

こんな感じで画面が推移し、TCP443でも証明書認証ができるようになります。

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

ここのところ、書籍執筆のご依頼が続き、なかなかブログを書けていなかったですが、ひと段落したので、再開していこうと思います。

ちょうど執筆を終えた書籍はAzure Information Protection (AIP)とWindows Information Protection (WIP) に関するもので(もう少ししたら、ちゃんとした情報をお伝えできる予定です)、それに関連して、WIPでMicrosoft Teamsの保護を行っていました。

WIPとは、アプリケーション内で扱うコンテンツをアプリケーションの範囲外に持ち出せないようにするテクノロジーで、Microsoft Intuneでポリシーを作り、Windows 10で適用するものです。実際にTeamsアプリに対してWIPによる保護を設定すると、

Teamsアプリ内の文字をコピーして、

他のアプリに貼り付けようとすると、ご覧のとおりエラーが出て貼り付けに失敗します。

このように、WIPは他のアプリにコピペすることによる漏えいを防げる優れもののソリューションなのです。
ところが、ブラウザーからTeamsのサイトにアクセスし、文字列をコピーすると、

他のアプリに貼り付けができちゃいます。

このようにTeamsのコンテンツは、アプリからのアクセスだけでなく、ブラウザーからのアクセスも可能です。また、ブラウザーの場合、URLでWIPの保護設定ができますが、Teamsのコンテンツにアクセス可能なURLは複数あるので、思いつくだけでも、次のエリアに対するWIPの保護設定をしなければなりません。

・Teamsアプリに対する保護設定
・ブラウザーからTeamsサイトのURL (https://teams.microsoft.com/)
に対する保護設定
・ブラウザーからSharePointサイトのURL
(https://xxxx.sharepoint.com) に対する保護設定

あと、TeamsってOffice 365グループでできてるから、Office 365グループの保護設定も必要になりますね。

Teamsのコンテンツは色々なURL、アプリからアクセス可能なので、そのすべてをふさぐようにWIPによる保護を設定することが大事になるので、WIPのようソリューションを導入するときはTeamsのアーキテクチャを理解することがとても大事になります。

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

突然ですが、5月22-23日に開催されるマイクロソフトのカンファレンス「de:code 2018」に登壇することになりました。

登壇するのは「重要データを守るための手法 Deep Dive ～ データ暗号化からBlockchainまで」というチョークトークのセッションで、日本マイクロソフトの安納さんと共に登壇させていただきます。チョークトークは簡単に私から様々なテーマをあげるので、皆でディスカッションしましょう、というセッションです。

私はAzure Information Protectionのパートを受け持つので、AIPの運用について語りたい人、ベストプラクティスを模索したい人はぜひご参加ください！

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

突然ですが、日経BPさんから「ひと目でわかるAzure Information Protection」が2018年5月28日に発売されることになりました。

随分と前からマイクロソフトのクラウドセキュリティソリューションである、Enterprise Mobility + Security (EMS)のトレーニングに関わらせていただいておりますが、その中のドキュメント暗号化のソリューションである、Azure Information ProtectionとWindows Information Protectionについて、まとめた書籍を出すことになりました。

多層防御という考え方にもあるように、セキュリティ対策を行うときは、あらゆる分野に対して抜け・漏れのない対策を施すことが重要だと言われていますが、EMSを使うとなると世の中の情報はAzure ADやMicrosoft Intuneのようなメインプロダクトに偏っていて、意外にAIP、WIPの分野の情報が少ないことがわかります。実際、AIPやWIPのお問い合わせをいただくことも多くなってきていたところに、書籍のお話をいただいたので、私の同僚の新井さんと共に執筆させていただくことになりました。

書籍では、AIPやWIPの基本的なアーキテクチャーから利用方法に至るまで、「ひと目でわかる」ように書いたので、安全なドキュメントの管理をしたい方、ZIP暗号化をいい加減やめたい方はご覧なってみていただければと思います。

■新刊情報 (日経BPさんのWebサイト)
http://ec.nikkeibp.co.jp/nsp/special_information001.shtml

2018年5月28日発売なのですが、日経BPさんに頑張っていただいたおかげで
de:code 2018で先行発売することになりました(日経BPさん、ありがとう！)。de:code 2018での日本マイクロソフトの安納さんと私のセッションでは、この書籍で紹介させていただいている内容をもとに色々とディスカッションしていこうと思いますので、de:code 2018のセッション共々よろしくお願いいたします。

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

先週は英国出張に出ていたこともあり、前回の投稿から時間が空いてしまいましたが、今回もご紹介です。
先日ご紹介した「ひと目でわかるAzure Information Protection」の書籍ですが、この書籍を使ったハンズオントレーニングをエディフィストラーニングさんで開催することになりました！

書籍を読んで実際に手を動かしてみたいと思っても、なかなか環境を用意するのも大変という方にピッタリです(しかも1日で学べる！)。書籍の内容に合わせてハンズオンでトライしていただけることはもちろんのこと、運用面でのベストプラクティスについても合わせてご紹介しようと考えていますので、ご興味のある方はぜひ参加してみてください。

■ひと目でわかるAzure Information Protectionハンズオントレーニング
https://www.edifist.co.jp/it/course/MSCAZ03

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

最近、お知らせばかりが続いていますが、今回もお知らせです。
2018年6月30日に開催される勉強会、Interact 2018に登壇することになりました。
テーマは

・Azure AD B2B
・ADFS + OpenID Connect

の2本立てです。
既に現時点で300名以上の申し込みがあるようで、これから申し込みできるのか、よくわからないですが、ご興味のある方は参加してみていただければと思います。
参加登録はこちらから。

https://interact.connpass.com/event/77420/

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

Microsoft Intuneで管理するWindowsデバイスと言えば、ワークグループPCであることが多かったですが、現実にはオンプレミスのActive Directoryドメインに参加しているPCをMicrosoft Intuneに登録させて使いたい、というニーズもあるかと思います。

ドメイン参加のPCをIntuneに登録する方法って、ネットで探してみると、
ありそうで、あんまり多くなかったりするので、今日はこのブログでチャレンジしてみようと思います。

Microsoft Intuneにデバイスを登録するときは、Azure ADへのデバイス登録も同時に行うことが事実上必須なので、

1．ハイブリッドAzure AD参加設定を利用して、ドメイン参加PCをAzure ADにデバイス登録
2．Azure ADにデバイス登録したPCがAADトークンを使ってMicrosoft Intuneにデバイス登録
3．同期ユーザーにIntuneのライセンスを割り当て
4．晴れてMicrosoft Intuneデバイスとして登録完了

という流れで、登録作業を進めていくことになります。
では、順番に作業を見ていきましょう。

ハイブリッドAzure AD参加の設定

ハイブリッドAzure AD参加とは、オンプレミスのActive Directoryドメインに参加しているPCをAzure AD ドメインにも参加させる機能のことです。設定方法は以前の投稿でも書いた通りなのですが、Azure AD ConnectのVersion 1.1.819.0以上を利用している場合はAzure AD ConnectからハイブリッドAzure AD参加の設定ができるようになりました。

Azure AD ConnectからハイブリッドAzure AD参加の設定を行うときは、
一度普通にAzure AD Connectをインストールした後、デスクトップに作られるショートカットを実行し、[追加のタスク]から[デバイスオプションの構成]を選択します。

その後、[ハイブリッドAzure AD参加の構成]を選択して、

オンプレミスADドメインとAzure ADドメインのマッピング設定を行い、

ハイブリッドAzure AD参加させるOS種類を選択します。特に、ダウンレベルのOSをハイブリッドAzure AD参加させる場合の設定は面倒なので、これで自動化できるのは結構便利ですね。

以上で設定は完了。ただし、これでハイブリッドAzureAD参加のためのすべての設定が完了か、と言うとそうではなく、グループポリシーの設定をしなければなりません。
グループポリシーはコンピューターの構成＞ポリシー＞管理用テンプレート＞Windowsコンポーネント＞デバイスの登録＞ドメインに参加しているコンピューターをデバイスとして登録する
このポリシー設定を有効にすればOKです。

AADトークンを使ってIntuneにデバイス登録

Azure ADに参加したデバイスは、AADトークン(詳細は割愛)をもらえるので、このトークンを持ってIntuneにデバイス登録させてくれ！というお願いをすれば、その願いは叶います。
設定は、グループポリシーから、コンピューターの構成＞ポリシー＞管理用テンプレート＞Windowsコンポーネント＞MDM＞AADトークンによる自動MDM登録
このポリシー設定を有効にすればOKです。

なお、このグループポリシー設定項目は、Windows 10 Version 1709以降で対応しているので、クライアントPC自身がWindows 10 Version 1709以降であることに加え、Windows 10 Version 1709以降のグループポリシーをドメインコントローラーに保存しておかなければなりません。その設定は、マイクロソフトのWebサイトよりツールをダウンロード・インストールし、インストールディレクトリからPolicyDefinitionsフォルダーをドメインコントローラーのC:\Windows\Sysvol\domain\policiesフォルダーにコピーすれば、上記のグループポリシー設定項目が表示されるようになります。

ユーザーの同期とライセンス割り当て

前の手順でAzure AD Connectをインストールしているので、オンプレミスのユーザーアカウントはAzure ADに同期されているはずです。ですので、Azure ADに同期されたユーザーに対して、Microsoft Intuneのライセンスを割り当てておきましょう。

クライアントPCで確認

ここまで設定が完了すれば、あとはクライアント側で確認するだけです。
確認するときは、ドメイン参加のPCでMicrosoft Intuneのライセンスが割り当てられたユーザーでサインインし、グループポリシーが適用されるのを待つだけです(せっかちな人はgpupdate /forceコマンドでどうぞ)。

Intuneへの登録が完了すると、設定アプリの[アカウント]-[職場または学校にアクセスする]にアクセスすると、オンプレミスADドメインに接続済みの項目に[情報]というボタンが増えてる！Intuneを普段からお使いの方ならご存知ですよね？[情報]ボタン→[同期]ボタンの順にクリックすれば、Intuneのポリシー設定を今すぐダウンロードしなさい、のボタンです。
つまり、[情報]ボタンが表示されているということはIntuneにデバイス登録が完了した証なのです。

デバイス登録が完了したことは、Azure管理ポータルでも、もちろん確認できます。

ドメイン参加PCがIntuneにデバイス登録すると、GPOとIntuneポリシーのどちらが優先されるのか？など、課題がまだまだあると思います。しかし、少なくともデバイスの種類を選ばずIntuneで管理できるので、皆さんの会社でもデバイス管理のクラウド化への第一歩を踏み出せるようになるのではないでしょうか？

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

最近、自分の仕事の範囲がものすごく拡張していて、Microsoft 365という枠組みの中でTeamsのセミナー/トレーニングまで手掛けるようになっています。Teamsの話をするときは必ずBotを作る話になるのですが、その際、QnA Makerを使って簡単にBotを作る方法を紹介させていただいています。
ところが最近、QnA MakerがPreviewじゃなくなったのと同時にAzureのサービスに移管されています。(ちなみにPreview時代に作ったQAのデータベースは
https://www.qnamaker.ai/old/Home/MyServices からアクセスできます)

新しいQnA Makerで作ったQAデータベースをTeamsに実装し、利用できる方法はどこどこで紹介されているので、そちらを参照してくださいね、って言おうと思ったら、日本語で情報がなかったんで、ひとつブログ投稿を書いてみることにしました。

Knowledge Baseの作成

QnA MakerのデータベースはKnowledge Baseと呼ばれており、QnA Makerを使ったBot作成はKnowledge Baseを作るところから始まります。

https://www.qnamaker.ai/ からQnA Makerのサイトにアクセスし、Azure管理者アカウントでサインインします。サインインしたら、[Create a Knowledge Base]-[Create a QnA service]からKnowledge Baseを新規作成します。

すると、Azure管理ポータルが起動し、QnA MakerのApp Serviceを作成することになります。

App Serviceが作成できたら、QnA Makerのページに戻り、Knowledge Baseの作成を再開します。Azure QnA Service欄には前の手順で作成したApp Serviceの名前を入れます。また、Populate your KBという欄ではQA集を作成するに当たり、どこのURLに書かれているFAQをインポートするか指定します。
ここでは、日本郵便のゆうパックに関するQ&Aを利用することにしました。

ゆうパックに関するQ&A 料金・オプションサービスから調べる
https://www.post.japanpost.jp/question/you_pack/category01.html

最後にCreate your KBをクリックして完成です。

出来上がったKnowledge Baseではゆうパックに関するQ&Aから引っ張ってきてQA集が確認できます。また、この画面で手動でQ&Aを追加することもできます。確認できたらPublishボタンを押して、

Publishボタンを押します。

すると、HTTP requestが生成されるので、これを控えておきます。

続いてAzureからBot用のApp Serviceを作成します。Azureの新規作成からAI + Machine Learning > Web App Botを選んで、

ボット名などを入力してApp Serviceを作成していきます。このとき、ボットテンプレートにはQuestion and Answerを必ず選んでください。

BotのApp Serviceができたら、[アプリケーション設定]項目を開き、次の項目の値を設定します。
QnAAuthKey：HTTP requestのAuthorization Endpointkeyの値
QnAEndpointHostName：HTTP requestのHostの値
QnAKnowledgebaseId：HTTP requestのURLに記載されているId部分の値
(上のサンプルでは1675a-…で始まる部分)

続いて、BotのApp Serviceの[チャンネル]項目を開き、Teamsアイコンクリックします。

すると、Microsoft Teamsがチャンネルに追加され、さらにそのリンクをクリックすると、

Teamsアプリが立ち上がり、Botが追加されることが確認できます。このBotは先に登場したQnA MakerのKnowledge Baseと連動していますので、Q&A集に沿って回答してくれます。

いかがでしたでしょうか？Botを作るというと、なんか難しそうなイメージがありますが、これだけの手順でできてしまうので、ぜひチャレンジしてみてください。あと、Microsoft AzureのWebサイトでも大まかな手順は紹介されているので、そちらも参考にしてみてください。

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

オンプレミスのActive DirectoryとAzure ADの間でオブジェクトの同期を行うAzure AD Connectですが、これに関してはとてもよくご質問をいただきます。そして、そのご質問の多くはPowerShellでできますよ！ってのが多いんですよね。

ですので、今日はよく(?)使う、Azure AD Connectのコマンドレットをいくつか紹介します。

■同期を今すぐ実行
これは普段から利用している方であれば、お馴染みですよね。
Deltaは差分の意味なので、DeltaをInitialと書き換えることでフル同期を行ってくれます。

Start-ADSyncSyncCycle -PolicyType Delta

■定期的な同期を行わない
たまにご質問いただくのですが、オンプレミスのADはもう変更しないので、一度同期したら、もう同期したくないのですが、どうしたらいいですか？っていう場合。このときは、同期設定を無効にしましょう。ディレクトリ同期を非アクティブ化するという手もあるのですが、再び同期をしたくなったら面倒なので、無効にしておくのが吉でしょう。

Set-ADSyncScheduler -SyncCycleEnabled $False

■同期間隔を変更
30分という同期間隔を変更したい場合。このときはSet-ADSyncSchedulerコマンドレットで変更します。ちなみに下のコマンドは3時間に変更しています。ただし、30分よりは短くできないので、ご注意を。

Set-ADSyncScheduler -CustomizedSyncCycleInterval 03:00:00

■パラメータの確認
Azure AD Connectのパラメータを確認した時はこれ。

Get-ADSyncScheduler

実行結果はこんな感じです。

結果画面に見えているパラメータはSet-AD SyncSchedulerコマンドレットから変更できます。例えば、Synchronization Service Managerに保存されるログの消去間隔(PurgeRunHistoryInterval)を変更したければ、

Set-AD SyncScheduler -PurgeRunHistoryInterval 1.00:00:00

のように設定します。

ちなみに、以前のバージョンのコマンドレットにはステージングモードの有効/無効設定があったのですが、私が使っているバージョン(1.1.819.0)では該当するコマンドレットがないんですよね。。

■Azure AD Connectの自動アップデートを行わない
簡易設定(だったっけ？)や、10万未満のオブジェクト数だったり、いくつかの条件に合致する場合、Azure AD Connectは自動的に新しいバージョンを見つけてアップデートします。しかもそのタイミングはWindows Update関係なく行われます。そのため、勝手にアップデートしてほしくない場合は、このコマンドレットを実行します。

Get-ADSyncAutoUpdate -AutoUpgradeState Disabled

なお、アップデートの結果はイベントビューアのアプリケーションログに記録されます。

■Azure AD Connectのトラブルシューティングツール
Azure AD Connectがらみのトラブルが発生した場合、こちらのコマンドレットから原因を調査できます。

Invoke-ADSyncDiagnostics

上記のPowerShellコマンドレットを実行すると、こんな画面が出てきます。

そこから3を選択すると、現状の設定をHTMLファイル形式で吐き出してくれます。

また、1を選択した場合であれば、特定のオブジェクトに関する状態情報を吐き出してくれます。この場合、ADのオブジェクト情報、Azure AD Connect内(メタバース)のオブジェクト情報、Azure ADのオブジェクト情報をそれぞれ確認できるので、どこまでの処理が正常に完了しているか、追っていくにはとても役立ちます。

いかがでしょうか？その他にもコマンドレットはあるのですが、追って追加していこうと思います。

皆さんこんにちは。国井です。
先日、Interact 2018というイベントでお話させていただいた
Azure AD B2Bについてですが、結構反響が大きかったので、
こちらのブログでも紹介しておきたいと思います。

Azure AD B2Bとは？

Azure AD B2Bとは、他のAzure ADテナントにいるユーザーを自分たちのAzure ADテナントにゲストユーザーとして登録することで、自分たちのAzure ADテナントに登録されているアプリに対するアクセス許可を他の会社のユーザーに割り当てられるようにしましょうという機能です。

Azure ADの信頼関係

仕組みとしては、OAuth2.0を使ったID連携を行っています。なので、もともとのユーザーがいるテナントとは別に、ゲストユーザーと呼ばれるユーザーを作成し、2つのIDを連携させるような設定を行わせるのです。

あと、以前の投稿の時点では、ゲストユーザーを登録した後、送信されるメールのリンクをクリックする必要がありましたが、現在はアクセス許可が割り当てられているクラウドサービス(アプリ)に直接アクセスして利用開始することも可能になっています。

登録方法

ゲストユーザーの登録設定は、Azure管理ポータルから行えるほか、PowerShellなどから行うことができます。

■Azure管理ポータルから作成
Azure管理ポータルの場合、[Azure Active Directory]-[ユーザー]から[新しいゲストユーザー]を選んで作成します。

■PowerShellから作成
Azure ADv2 PowerShellから、New-AzureADMSInvitationコマンドレットを使って作成します。

New-AzureADMSInvitation -InvitedUserEmailAddress <招待するAzure ADユーザー名> -SendInvitationMessage $True -InviteRedirectUrl "http://myapps.microsoft.com" -SendInvitedUserType guest

基本的にInvitedUserEmailAddressオプションで指定したメールアドレスにメールが送られますが、もしメールを送りたくない場合は、-SendInvitationMessage $Falseとしてください。
ここまでの設定で、ゲストユーザーが作られ、アクセスパネル(http://myapps.microsoft.com) へのアクセス許可が割り当てられたことになります。
最後に余談ですが、New-AzureADMSInvitationコマンドレットには-SendInvitedUserTypeというオプションがあります。デフォルトの値はguestという設定ですが、memberと指定することもできます。memberにすると、他の一般のAzure ADユーザーと同じユーザーの扱いになるので、Azure管理ポータルからユーザー一覧が見えちゃうなどの問題が発生します。

■CSVファイルから作成
事前に以下のようなCSVファイルを作っておき、Azure ADv2 PowerShellを使って実行します(そういえば、Interact 2018の資料のスライド8のコマンドは間違ってましたね。
正しくは↓こちら↓を参照してください)。

・CSVファイルのサンプル

Email
kunii@adfs.jp
arai@adfs.jp

・PowerShellコマンドレットのサンプル

$Invites = Import-Csv <CSVファイルのパス>
Foreach ($Invite in $Invites) {
New-AzureADMSInvitation -InvitedUserEmailAddress $Invite.Email -SendInvitationMessage $True -InviteRedirectUrl "https://myapps.microsoft.com" -SendInvitedUserType guest
}

■クラウドサービス(アプリ)から作成
OneDrive for Businessの共有設定や、Azure Information Protectionのアクセス許可設定などで、社外(自分たちのAzure ADテナント外)のユーザーにアクセス許可を割り当てると、実は裏ではAzure AD B2Bの機能を通じて、ゲストユーザーが作成されています。

こちらのブログでも紹介されているように、これが結構困ったことになるんですよね。。

次回は、いつの間に作られるAzure ADの話をしてみたいと思います。

皆さんこんにちは。国井です。
前回はAzure AD B2Bでゲストユーザーの作り方について紹介しました。
このとき、ゲストユーザーとして作成するユーザーは元のユーザーがいる前提であるかのように語っていましたが、実は元のユーザーがいなくても作れます。

では、元のユーザーがいない状態でゲストユーザーを作ったら、どうなってしまうのでしょうか？今回は、パターン別にゲストユーザーを作成したときの影響についてみてみます。

既にAzure ADテナント/ユーザーが作られている場合

ゲストユーザーを登録するAzure ADテナントの相手となるAzure ADテナント(画面下で言うところのパートナーテナント)が既に作られており、Azure ADユーザーも作られている場合、ゲストユーザーを作成すると、前回紹介させていただいたような(単純に)ゲストユーザーを登録する作業が処理されます。

ゲストユーザーとして登録されたユーザーは送られてきたメールのリンクをクリックするか、アクセス許可が割り当てられているクラウドサービス(アプリ)にアクセスし、初回アクセス時にOAuth2.0の同意画面で同意することで、

ゲストユーザーが利用開始できるようになるのと同時にアプリへのアクセスも開始できるようになります。これまでの投稿でも解説してきたような普通の動きです。

マイクロソフトアカウントを登録する場合

ゲストユーザーとして登録するユーザーがマイクロソフトアカウントの場合、他のテナントのAzure ADユーザーと同じように登録が可能です。

ゲストユーザーとして登録されたユーザー(マイクロソフトアカウント)は送られてきたメールのリンクをクリックするか、アクセス許可が割り当てられているクラウドサービス(アプリ)にアクセスし、初回アクセス時にOAuth2.0の同意画面で同意することで、ゲストユーザーの登録が完了します。最初のパターンと変わることはなにひとつありません。

Azure ADユーザーがまだ存在しない場合

既にAzure ADテナントはあるが、Azure ADユーザーがまだ存在しない場合は少しやっかいです。ゲストユーザーを登録し、メールのリンクをクリックすると、アクセス許可のあるクラウドサービス(アプリ)にアクセスできるようになるのですが、同時にゲストユーザーを登録したAzure ADテナントの相手となるテナント(画面下のパートナーテナント)にAzure ADユーザーが自動的に作られます。

Azure ADユーザーが勝手に作られると言っても、Azure ADユーザーのパスワードとかどうなるの？って思うかもしれません。そこは次のような仕組みでパスワードが設定され、ユーザーが作成されます。

ゲストユーザーとして登録されたユーザー(メールアドレス)は、メールのリンクをクリックしたタイミングで、Azure ADユーザーのパスワード設定画面が下のように出てくるのです。

ここでパスワードを設定すると、そのパスワードがAzure ADユーザーのパスワードとして使われることになり、ユーザーが勝手に作成されます。
そのため、理解して使わないと、勝手にユーザーが増える事態になりますから注意が必要です。

まだAzure ADテナント/ユーザーが存在しない場合

Azure ADユーザーどころか、Azure ADテナントもまだ存在しない状態でゲストユーザーを作成すると、メールのリンクをクリックしたタイミングでAzure ADテナントとAzure ADユーザーを勝手に作ります。

画面ショットがないので、わかりやすくないかもしれないですが、メールのリンクをクリックすると、そのユーザーのパスワード設定画面と同時に、国または地域を選択する画面が表示されます。この、国または地域の選択画面はAzure ADテナントの作成に必要な情報を聞いてきているんですね。ですので、これらの情報の入力が完了すると、Azure ADテナントとユーザーを作成するための情報が整い、すべてが勝手に作られてしまうのです。

勝手に作られたAzure ADテナントは、どう管理する？

勝手に作られたAzure ADテナントは管理者がいない状態のテナントとなります。管理者がいない状態から、新しく管理者を定義するときは勝手に作られたAzure ADテナントのユーザーでAzure AD PowerShellにサインインし、Azure ADテナントに登録されたドメインの承認作業を行います。
最初に以下を実行し、(1行で実行してください)

Get-MsolDomainVerificationDns -DomainName <ドメイン名> -Mode DnsTxtRecord

TXTレコードを取得して、DNSサーバーにTXTレコードを登録したら、

Confirm-MsolEmailVerifiedDomain -DomainName <ドメイン名>

と実行することで、カスタムドメインの本登録が完了すると同時にこの操作を行ったユーザーがAzure ADテナントの全体管理者に昇格します。

これで勝手に作られたAzure ADテナントを管理できるようになるのですが、勝手に作られたAzure ADテナントの勝手に作られたAzure ADユーザーが管理者にしたいユーザーとは限らないですよね。これがまたこの運用の大変なところでもあるのです。

次回はどんなタイミングでAzure ADテナントやユーザーが作られるのか、見ていく予定です。

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

ちょっと間が空いてしまいました。前回はパターン別にゲストユーザーがどのように作られるかについて確認しました。そのときに紹介したパターンはいずれもゲストユーザーを明示的に作成しようとしていました。しかし、ゲストユーザーはアプリからの操作によって勝手に作られてしまうパターンもあるのです。
そこで、今日はアプリから作られてしまうパターンを見てみましょう。

OneDrive for Businessから作られるパターン

OneDrive for Business (ODfB) は基本的に自分専用のクラウドストレージですが、共有設定を行うことによって、別のユーザーにアクセス許可を割り当てることができます。このとき、割り当てるユーザーにはAzure ADユーザーまたはマイクロソフトアカウントを指定できます。
もうお気づきかもしれませんが、ODfBでアクセス許可を割り当てるときに、自分のドメイン以外のAzure ADユーザーに対してアクセス許可を設定すると、自動的にゲストユーザーが作られます。

(私のODfBで色々な会社の人と共有設定したおかげで、弊社のユーザー一覧はゲストユーザーだらけでございます)
しかも、共有設定は要らなくなった共有解除すればいいけど、ゲストユーザーは勝手に削除されません。そのため、ゲストユーザーが一方的に増え続ける仕様になっています。

Azure Information Protectionから作られるパターン

ファイルの暗号化機能である、Azure Information Protection (AIP) には、AIPのライセンスを持っていない人向けに、暗号化されたファイルにアクセスするだけの専用ライセンス(個人用RMS)を取得することができます。そのライセンスを取得するときにはメールアドレスを指定するのですが、outlook.comやhotmail.comなどのフリーのメールアドレスでなければ、どのようなメールアドレスでもライセンスが取得できるという便利なものです。
しかし、裏では入力したメールアドレスが既にAzure ADユーザーまたはマイクロソフトアカウントであるかをチェックし、どちらにも当てはまらない場合には自動的にAzure ADユーザーを作成してしまいます(前回紹介した、勝手にAzure ADのディレクトリやユーザーが作られるパターンです)。
例えば、私はso-netのメールアドレスを持っているのですが、個人用RMSのライセンスをso-netのメールアドレスで取得すると、裏では勝手にAzure ADユーザーが作られるので、そのユーザー名とパスワードを使って https://portal.azure.com/ にアクセスすると、、

ご覧のように、同じプロバイダーを使っている他人のメールアドレスが晒されてしまいます(和田さん、ごめんなさい。てか、和田さんって誰？)。

ここでは、ODfBとAIPのパターンを紹介しましたが、他にもMicrosoft Teamsを使ったパターンとか、SharePoint Onlineを使ったパターンなど、色々なケースでのトラブルが考えられそうです。

じゃあ、どうすりゃいいのさ？

残念ながら、すべてのコントロールができるわけではないですが、何もしないよりはマシなソリューションとして、Azure管理ポータルにある外部ユーザーの設定を変更する方法があります。(Azure管理ポータル > Azure Active Directory > ユーザー設定 > 外部コラボレーションの設定を管理します)

設定項目の中から[メンバーは招待ができる]を[いいえ]にしておけば、ODfBでゲストユーザーが事前に作られていない限り、外部ユーザーに対するアクセス許可を割り当てることができますので、[メンバーは招待ができる]などは、うまく活用するとよいかもしれません。

それから、[ゲストのアクセス許可を制限する]というのがありますが、これはゲスト管理者権限を割り当てさせないという設定なので、必ず[はい]にして運用してください。

また、勝手にAzure ADディレクトリ、ユーザーが作られる問題は、私たちのAzure ADから他のAzure ADに対する何かの制限が設定できるわけではないので、例えばパートナーに個人用RMSのライセンスを取得するときに勝手にAzure ADディレクトリが作られる可能性があることを認識してもらってから使う(認識してもらったら、使わないような気がするけど)、などの呼びかけぐらいしかできないと思います。

■ ■ ■

3回にわたって、Azure AD B2Bの機能についてみてきました。便利な機能であることは間違いないのですが、他の機能との兼ね合いで構造上の問題を持ってしまっているように思います。早く解決してほしいと思いますし、現時点で私たちにできることは、こうした事実を認識するってことだと思います。

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

書籍の執筆だったり、その他色々な執筆・登壇依頼をいただいており、なかなかブログを書く時間が取れないため、間が空いてしまいましたが、今日はAzure AD B2Bシリーズの第4弾を届けします。

■ ■ ■

Azure B2Bに関しては前回の投稿から新しくAzure ポータルのAzure AD内に[組織の関係]という項目が新設されました。

[組織の関係]項目では招待したユーザーのうち、相手が招待メールをクリックして招待を受け入れたり、招待されたアプリにアクセスしたりしたユーザーの一覧が表示されます。B2Bユーザーだけが一覧で表示されるので、不適切な招待が行われていないか？一度は招待したけど、もう関係を継続する必要のないユーザーがいないか？などをチェックできます。

また、別のIDプロバイダーで認証したユーザーを自動的にAzure ADユーザーとして扱えるような連携設定ができたり(これについてはMVPふじえさんのブログで紹介されているので、そちらを参照してください)、
前回紹介した[外部コラボレーションの設定を管理します]設定も[組織の関係]の中から設定できたり、

[組織の関係] – [使用条件]をクリックすると、招待されたユーザーが招待を承諾するときに、あらかじめ用意した使用条件に同意した上でAzure ADディレクトリを利用させるような設定が可能です。さらに、使用条件の設定には条件付きアクセスも同時に作成できるので、

条件付きアクセスを上の画面で選択するだけで、ゲストユーザーは使用条件に同意しないと、クラウドサービスへアクセスできないような条件付きアクセスポリシーが自動生成されます。

使用条件を設定した上で招待されたユーザーがメールのリンクをクリックすると、こんな感じの使用条件が表示されます。

また、使用条件に同意すれば、Azure管理ポータル側では使用条件に同意したユーザーの一覧が確認できます。

その他、[アクセスレビュー]という項目を使えば、特定ユーザーからのアクセスを管理者が承諾し、一定期間だけアクセスを許可させるような運用もできます。これについては、少しまとめてからお伝えしたいので、またの機会に。

■参考URL
Member ユーザーと Guest ユーザーについて
https://blogs.technet.microsoft.com/jpazureid/2017/12/12/azuread-member-guest/

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

「SCCMを使ってWindows 10を管理したいのに、なぜか日本語で得られる情報が少ない」

とはよく聞く話ですが、なかなかこの問題は解決しません。そんな折、LinkedIn Learningさんからお話をいただき、e-Learningのコースをリリースすることになりました。

■System Center Configuration Manager 基本講座
https://www.linkedin.com/learning/system-center-configuration-manager-essential-training?trk=featured-topics-card_course_title

コース自体は有償ですが、いくつかのトピックについては無料でご覧いただけるものもありますので、ぜひご覧になってみてください。
更新プログラム管理のアーキテクチャのトピックも無料にしておきましたので、WSUSとの違いを知りたい人、SCCMで更新プログラム管理をする人はぜひご覧になってみてください！

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

セキュリティという観点でのオンプレミスとクラウドの違いを語るとき、オンプレミスではファイアウォールを使ったネットワークベースの境界で守るのに対して、クラウドの場合にはIDを利用したバーチャルな境界で守る、という話をよくします。
IDを利用したセキュリティ対策と言っても、それがユーザー名とパスワード(だけ)では心もとないです。かと言って、多要素認証を利用することになれば、手間ばかりが増えたという印象をユーザーに持たれてしまいます。そこで最近、Azure ADではユーザー名とパスワードに代わる認証方法というのを模索しています。
Azure ADでは次の3つの方向でパスワードに代わる認証方法を提供しようとしています。

・Windows Hello for Business
・FIDO 2.0
・Microsoft Authenticator

今日はこのうち、Microsoft Authenticatorを利用した方法がプレビューで出てきたので試してみたいと思います。Microsoft Authenticatorを使った認証方法は、パスワードを入力する画面で2桁の数字が表示されるので、

それと同じ数字を携帯電話にあらかじめインストールしたMicrosoft Authenticatorアプリから選択することで、認証を完了する方法です。

■ ■ ■

簡単に概念だけ説明しておくと、Microsoft Authenticatorを使った認証方法はWindows Hello for Businessなどと同じく証明書ベースの認証を行っています。
Windows Hello for Businessの場合は、デバイスのTPMに秘密鍵を入れておいて、顔認証やPINなどを使った認証の後に秘密鍵にアクセスできるようにしていますが、
Microsoft Authenticatorを使った認証では、Microsoft Authenticatorアプリをインストールした携帯電話の中に秘密鍵があります。
秘密鍵には、上記で紹介したようにMicrosoft Authenticatorを使った認証プロセスを完了することによってアクセスできるようになります。

Microsoft Authenticatorによる認証の有効化

この投稿を書いている時点(2018年10月)ではプレビューですが、Microsoft Authenticatorによる認証を利用するにはAzure ADディレクトリの単位で有効化設定を行います。
有効化設定は、Azure AD PowerShellのプレビュー版をインストールし、PowerShellから行います。
実行するコマンドレットはこちら。

Azure AD PowerShellプレビュー版のインストール

Install-Module AzureADPreview

認証の有効化設定

Connect-AzureAD
New-AzureADPolicy -Type AuthenticatorAppSignInPolicy -Definition '{"AuthenticatorAppSignInPolicy":{"Enabled":true}}' -isOrganizationDefault $true -DisplayName AuthenticatorAppSignIn

個々のデバイスでの設定

手持ちの携帯電話(iOS, Android)では、Microsoft Authenticatorをインストールし、Azure ADアカウントとデバイスの関連付け設定を行います。
まず、アクセスパネル (https://myapps.microsoft.com/) を開いてプロファイル > 追加のセキュリティ確認 の順にアクセスして [認証アプリ] にチェックをつけ、QRコードを表示させます。

一方、携帯電話ではMicrosoft Authenticatorを起動し、アカウントを追加します。すると、QRコードの追加画面が出るので、読み取るとアカウントがアプリ内に追加されます。

アカウントが追加された右上のメニューをタップすると、[電話によるサインインを有効にする]というのが出てくるので、これをタップします。
このとき、携帯電話がAzure ADへデバイス登録されていない場合、右側のような画面が出るので、画面の指示に従ってデバイス登録を行います。

ここまでが完了したら、設定は完了です。実際にPCからAzure ADユーザーを利用してサインインを行います。すると、ユーザー名を入力したところで、2桁の数字が表示されます。

携帯電話では、Microsoft Authenticatorから通知が来ています。通知に応答すると、
ご覧のような3択問題が出てきます。PCに表示された数字と同じ数字を入力し、
さらに携帯電話のロック解除するときの認証(iOSなら指紋認証など)を行えば
サインインは完了です。

3択というのがどの程度の強度なのかよくわかりませんが
3択の女王だったら当ててしまうかも
いずれにしてもMicrosoft Authenticatorを使った認証＋携帯電話の認証の2要素で
パスワードよりも簡単に、かつパスワードよりも強力に認証を実行できます。

■参考情報
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-phone-sign-in

https://docs.microsoft.com/en-us/azure/active-directory/user-help/microsoft-authenticator-app-phone-signin-faq

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

2018年11月5-7日で開催されるTech Summit 2018ですが、Microsoft Intuneのお話をさせていただくことになりました。

セッションでは、Microsoft Intuneを利用してポリシー管理を行う方法について解説します。
長い間、Microsoft Intuneをクラウド版グループポリシーとして考えるのは無理があるだろうと言われてきましたが、最近のMicrosoft Intuneはだいぶ変わってきていますよ、という話をします。

セッションにご参加いただいた方にはランチがいただけるらしい？のと、ちょっとしたお土産をご用意しているので、Tech Summitにご参加の方はぜひ立ち寄っていただければと思います。(MVPふじえさんのセッションと同時刻というのが、すごい残念なスケジュール設定ですが..)

また、当日は日経BPさんから11月に発売予定の「ひと目でわかるIntune」の先行発売もあるので、こちらもどうぞよろしくお願いいたします。

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

今回もお知らせなのですが、Azure Active Directoryとは？というレベルから学習したいという方向けに新しくゾーホージャパンさんとのコラボで
【MicrosoftのMVP解説！Azure ADの虎の巻】というコラムを始めました。

コラムの中では、Azure ADとは何？なんのために使うの？というところから、具体的な使い方、運用方法までをやさしく解説していく予定です。

このブログでも、「Azure ADとは？」という検索キーワードで入ってくる方が多いので、ぜひ参考にしていただければと思います！

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

今日はMicrosoft Intuneのプロファイル設定の話です。
Microsoft Intuneのプロファイル設定は、オンプレミスで言うところのActive Directoryから提供されるグループポリシー(GPO)に当たると思います。

Active Directoryドメインに参加しているデバイスであれば、GPOが適用されるでしょうし、

Microsoft Intuneに登録されているデバイスであれば、Intuneからプロファイル(ポリシー)が適用されます。

しかし、Hybrid Azure AD Joinと呼ばれる方法で、Active DirectoryドメインとAzure ADドメインの両方に参加している場合、GPOとIntuneのプロファイルが同時に適用されます。

このとき、GPOとIntuneのプロファイルで相反する設定が施された場合、どちらの設定が適用されるのか？という問題があります。
結論から先に言うと、GPOとIntuneのプロファイル設定はGPOの設定が優先されます。
GPOからIntuneへの移行をするときにGPOが優先されたら、いつまで経ってもIntuneに移行できないという問題があります。

Intuneでは Windows 10からレジストリ設定で
HKEY_LOCAL_MACHINE_Microsoft\PolicyManager\current\device\ControlPolicyConflict
から MDMWinOverGP項目を作り値を1と設定することでIntuneのプロファイルを優先するように構成できます。

この設定をIntuneからまとめて設定したいということであれば、Intuneプロファイル設定のOMA-URIを利用して上記のレジストリ相当の設定をしてしまえばよいのです。
設定はMicrosoft 365デバイス管理ポータル(https://devicemanagement.portal.azure.com)から、
デバイス構成 > プロファイル > プロファイルの作成
からプロファイルを新規作成し、Windows 10 のカスタム設定を開き、

OMA-URIの設定として次の内容を追加します。

OMA-URI：./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinOverGP
データ型：整数
値：1

以上の設定ができたら、後は該当のデバイスグループに割り当てるだけ。
これでIntuneのプロファイルが優先されます。

GPOとIntuneの両方を利用する環境自体、多くないかもしれないですが、
今後、クラウドシフトをしていく中での一環で必要になるかもしれないので、覚えておきたい設定ですね。
なお、今回登場したMicrosoft Intuneについては、日経BPさんより「ひと目でわかるIntune クラウドで始めるモバイルデバイス管理」が2018年11月8日にリリースされるので、そちらも参考になさってください。

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

Tech Summit 2018では、本当にたくさんの方にお越しいただき、ありがとうございました。
今日は、そのTech Summit 2018のセッションのデモでしくじったIntuneからWin32アプリの展開方法についてです。

Intuneでは最近、.msiファイルだけでなく、.exeファイルもクライアントに展開できるようになりました。Windowsアプリのセットアッププログラムの大半がsetup.exeのような形式で提供されていることを考えれば、これは画期的なことだと思います。ところが、Intuneのポータル画面を見ると、setup.exeがそのまま登録できないような形式になっているんですよね。

じゃあ、どうやって登録していけばよいかを見ていきます。

.intunewinファイルの作成

Intuneから.exe形式のセットアッププログラムを展開するときは、セットアッププログラムを.intunewinという拡張子に変換しておく必要があります。
この設定は、GitHubからツールが出ているので、これを使います。
GitHubからダウンロードしたら、続いて実際に.intunewinに変換するセットアッププログラムを用意します。今回は、7zipを使うことにします。

ダウンロードした7zipのセットアッププログラム(7z1805-x64.exe)をc:\7zipフォルダーに、生成された.intunewinファイルを保存場所としてc:\intunewinフォルダーをそれぞれ用意したら、GitHubからダウンロードしたツールのうち、IntuneWinAppUtil.exeを次のように実行します。

IntuneWinAppUtil.exe -c c:\7zip -s 7z1805-x64.exe -o c:\intunewin

実行時の処理の様子がこちら。

出来上がったファイルをIntuneに登録します。

Intuneにセットアッププログラムを登録

.intunewinファイルを登録します。
Microsoft 365デバイス管理ポータル(https://devicemanagement.portal.azure.com/)から
クライアントアプリ ＞ アプリ ＞
[アプリの種類]から[Windowsアプリ(Win32)]を選択し、まずは.intunewinファイルを登録します。

続いて、残りの項目も埋めていきましょう。

[アプリ情報]の項目はインストールするアプリの情報を入力し、
[プログラム]の項目はインストールするときのオプションスイッチを指定します。
ちなみに、7zipの無人インストールは/Sを使います。
アンインストールのオプションスイッチは.. ごめんなさい、適当に入れちゃいました。
あと、[インストールの処理]部分は、[システム]を選択すれば、すべてのユーザー用にインストールされます。

それから[必要条件]の項目は、インストール要件を定義します。

[検出規則]の項目では、どのような状態だったら、既にアプリがインストールされているか？という条件を設定します。
例えば、c:\Program Files\7zipフォルダーがあったら、既にインストールされていると判定する場合であれば、
[規則の形式]から手動を選択して、フォルダーを直接指定します。
[規則の形式]では、特定のレジストリ項目があるか？とか、PowerShellスクリプトを使って判定させたりすることも可能です。

ここまで出来たら、[追加]ボタンをクリックして登録します。登録が完了したら、ユーザーまたはデバイスへの割り当てもお忘れなく。

で、ここからが大事なポイントですが、
Win32アプリのインストールは、Intune経由でPowerShellスクリプトを実行するときに使う、Intune Management Extensionエージェントを利用します。そのため、Intune Management ExtensionエージェントをサポートするWindows 10クライアント、つまりAzure AD参加していることが前提条件になります。
(一部の方に、Azure ADに登録されているだけでも設定されました、と言ってしまいましたが、あれは幻だったようです)あと、ハイブリッドAzure AD参加もOKだという話を人づてに聞いたのですが、後で検証してみます。