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

以前、Office 365 MDM 機能を紹介させていただき、Office 365 MDMはMicrosoft Intuneのサブセットであり、Microsoft Intuneのライセンスを利用しているとOffice 365 MDMが利用できない、という旨の話をしました。

ところが、仕様が変わったのか、私の確認が間違っていたのか、よくわかりませんが、現時点(2015年8月時点)では以前の投稿とは少し異なる点があるので、Microsoft Intuneの視点から紹介しておきます。

Microsoft Intuneはモバイルデバイスの管理を行うにあたり、[モバイルデバイス管理機関]という設定を行う必要があります。これまでは、モバイルデバイス管理機関の選択肢はMicrosoft IntuneまたはSCCMの2択だったのですが、最近、Office 365が加わりました。

そして、選択肢は一度選択したら、あとから変更できないという話はMicrosoft Intuneを活用されている人の間では有名な話でした。

モバイルデバイス管理機関としてSCCMを選択する場合、SCCMからIntuneのテナントを登録する必要があるため、SCCMをインストールしていなければ、間違って登録することはなかったのです。

ところが、Office365の場合はちょっと間違えると、ご覧のようにモバイルデバイス管理機関がOffice 365に設定され、変更できなくなってしまいます。

モバイルデバイス管理機関をOffice365に設定される場所は、私が確認した限りでは
ドメインの役割選択を行う、以下の設定がトリガーになっているようです。

Mobile Device Management for Office 365にチェックをつけ、この後の画面で提示されるDNSレコードを登録すると、モバイルデバイス管理機関がOffice 365に設定され、Intuneのモバイルデバイス管理機能は利用できなくなります。

私自身は経験がないのですが、サービスリクエスト(SR)をあげて設定解除できるという話を風のうわさで伺いました。SRをあげると多少なりとも時間がかかりますので、そもそもこのようなトラブルに巻き込まれないように注意したいですね。

2015年8月20日追記
サービスリクエストをあげていただくことにより、モバイルデバイス管理機関は変更できますよ、とご連絡をいただきました。モバイルデバイス管理機関の変更方法やモバイルデバイス管理機関そのものの説明などを日本マイクロソフトさんのブログで紹介しておりますので、合わせて参考にしてください。
http://blogs.technet.com/b/jpintune/archive/2015/08/20/microsoft-intune-mdm-for-office-365-sccm.aspx

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

今週はAzure ADとMicrosoft Intune関連の情報を連続して投稿しています。
連投でそろそろ肩が壊れそうです。

今日は、Azure AD Premiumの機能として先日登場したAAD Connect Healthという機能を使ってみましたので、ここにも掲載しておきます。
AAD Connect Healthとは、Azure Active Directory Connect Healthの略で、オンプレミスに実装したADFSサーバーやプロキシの状態をクラウドから監視するだけでなく、ADFSサーバーの利用状況なども併せて確認できる、監視ツールです。

■Azure Active Directory Connect Health
https://msdn.microsoft.com/ja-jp/library/azure/Dn906722.aspx

AAD Connect HealthはMicrosoft Azureの新しいポータルから利用可能なツールで、
[セキュリティ＋ID]-[Azure AD Connect Health]から新しいインスタンスを作成します。

どのAzure ADドメインで利用するかを選択し、

[クイックスタート]をクリックして、

[Download Azure AD Connect Health Agent for ADFS]をクリックして、ツールをダウンロードします。

ダウンロードしたツールはADFSサーバー上で実行し、インストールします。

インストールが完了したら、[今すぐ構成する]をクリックし、

Azure ADの管理者アカウントでサインインすると、

PowerShellスクリプトが実行されて構成されます。

インストールが完了したら、Azure管理ポータルを参照します。すると、エージェントがインストールされたADFSサーバーの台数が表示され、ADFSサーバーの稼働状況が確認できます。
また、画面右下に注目すると、

24時間以内にADFSサーバーを経由して、どのようなアプリケーションへのアクセスがあったかやトークンの発行数などが確認できます。ただし、アプリケーションは名前ではなく、ADFSサーバーに登録されたURNと呼ばれる識別名で表示されるので、少しわかりにくいです。(ちなみに、urn:federation:MicrosoftOnlineというのがOffice365へのシングルサインオンです。)
このあたりはURNではなく、証明書利用者信頼の名前で表示するなど、していただけると、よりわかりやすいかなと。
今後の改善に期待ですね。

なお、アプリケーションへのアクセス状況等は、ADFSサーバーのセキュリティログから情報を抽出して表示しているので、セキュリティログにADFSのアクセスログが残るよう、事前に設定しておく必要があります。この設定についてはMVP渡辺さんのブログで紹介しているので、合わせて参考にしてください。

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

先日、Azure ADのセミナーで、「Azure ADの多要素認証プロバイダーで、モバイルアプリを利用する場合、どのような設定が必要ですか？」というご質問をいただきました。

ざっくりとした回答を申し上げると
「多要素認証プロバイダーのポータルサイトからモバイルアプリのアクティブ化を実行してください」となるのですが、私の環境で実際に構築したところ、うまく動作しないところがありましたので、これについては手順がまとまりましたら、改めてご紹介します。

今日はその前提条件となる多要素認証プロバイダーのポータルサイトが実は様々な管理作業を行うのに、とても便利なので、ポータルサイトそのものの紹介をさせてください。

多要素認証プロバイダーのポータルサイトは、本来Azure管理ポータルやMulti-Factor Authentication Serverの管理ツールから行うような設定をMulti-Factor Authentication ServerのWebサイトからできるようにしたもので、Multi-Factor Authentication Serverに直接アクセスできないような環境のときに利用すると便利だと思います。

例えば、「ユーザーから多要素認証のワンタイムバイパスを行ってほしいと言われたけど、管理者は外出しているので、外出先からワンタイムバイパスの設定を行いたい」などというニーズが考えられます。
そういうときには、Multi-Factor Authentication ServerのWebポータルをインターネットに外部公開しておけば、どこからでもMulti-Factor Authentication Serverの各種設定ができますね。(そのほかにもいろいろな操作が可能で、下のポータルサイトの画面を見てもらえれば、何ができるか確認できると思います。)

また、多要素認証プロバイダーのポータルサイトは「ユーザーポータル」と一般的に呼ばれており、その名前からもわかるように(管理者ではなく)ユーザー自身が多要素認証に関わる各種設定を行うことができます。
(今日はご紹介しませんが、モバイルアプリを利用するときのアクティブ化設定などができます。)

このようなポータルサイト(ユーザーポータル)なのですが、利用するには、次の前提条件があります。

・ユーザーポータルの利用には多要素認証プロバイダーのWebサービスSDKのインストールが必要
・多要素認証プロバイダーのWebサービスSDKのインストールには、IISとIIS6メタベース互換のインストールが必要

では、前提条件をクリアしながら、ユーザーポータルを実装してみましょう。
(ちなみにMulti-Factor Authentication Serverそのもののインストールも必要ですが、それはこちらに記載しました)

■　■　■

まず、IISとIIS6メタベース互換ですが、Multi-Factor Authentication Serverがインストールされたコンピューターに[役割と機能の追加]からインストールしておいてください。

次に、WebサービスSDKのインストールはMulti-Factor Authentication Serverの管理ツールを起動し、[WebサービスSDK]をクリックして、[WebサービスSDKのインストール]を実行して始めます。

[WebサービスSDKのインストール]を実行すると、ウィザードが開始しますが、基本的にはすべて次へで進めていけばOKです。WebサービスSDKで使用するIIS Webサイトのディレクトリ名は自由に指定可能なので、必要に応じて変更してください。ここではディレクトリ名はそのままにしてインストールを完了します。

次に、ユーザーポータルをインストールします。ユーザーポータルのインストールはMulti-Factor Authentication Serverの管理ツールから[ユーザーポータル]をクリックして、[ユーザーポータルのインストール]を実行して始めます。

インストールが完了したら、Multi-Factor Authentication Serverの管理ツールで、ユーザーポータルのURLとして、
https://<多要素認証プロバイダーサーバー名>/MultiFactorAuth/と入力しておきます。
そのほか、各種チェックボックスにチェックをつけておくと、ユーザーポータルにサインインしたユーザーが自分でできる操作を決定できます。
それから[ユーザーにログインを許可する]にチェックをつけておくことをお忘れなく。

[信頼できるIP]タブをクリックし、ユーザーポータルにアクセスするクライアントのIPアドレス範囲を指定します。これにより、指定したIP範囲以外からはポータルサイトにアクセスできないので、社内イントラのIPアドレスを設定したら、ポータルへのアクセスは社内からしかできなくなるので注意が必要です。

[管理者]タブをクリックし、管理者となるユーザーも設定しておきましょう。
管理者を登録し、管理者ができる操作も同時に定義しておきます。

■　■　■

ここまでで設定完了です。
では、早速アクセスしてみましょう。
ポータルサイト(https://<多要素認証プロバイダーサーバー名>/MultiFactorAuth/)にアクセスし、管理者となるユーザーの名前とパスワードを入力すると、

冒頭で紹介したポータルにアクセスできました。
このうち、[ユーザーの管理]という部分が管理者ができる作業項目、[マイアカウント]という部分が自分自身の作業ができる項目です。

では、今回は管理者として、ユーザーの多要素認証のワンタイムバイパスを設定してみましょう。ここでは、[ユーザーの検索]をクリックしてバイパスするユーザーを検索し、
検索結果から、バイパスの操作を行います。([ワンタイムバイパス]というメニューがありますね)

ワンタイムバイパス画面では、バイパスする時間を設定します。ワンタイムバイパスはワンタイムではなく、秒数なのですね。。

設定が完了すると、設定した秒数以内にサインインすると、多要素認証をスキップできます。
実際にサインインしてみると、多要素認証を要求する画面は表示されますが、実行すると、

何も多要素認証の操作を行うことなく、目的のサイトにシングルサインオンできます。

いかがでしょうか？

ワンタイムバイパス以外にも様々な操作ができるようなので、多要素認証プロバイダーの利用を検討している方はぜひご自身で実装し、確認してみてください。

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

以前、当ブログでAlternate Login ID(代替ログインID)という方法を利用して、Office365(Azure AD)のシングルサインオン(SSO)を構成する方法を紹介しました。
Alternate Login IDを使うとディレクトリ同期やSSOにUPNを使わなくなるので、kunii@example.localのようなUPNでも、代替UPNサフィックスを使わないでSSOができるという、ありがたいお話でした。

しかし、その設定は結構面倒だったのですが、AAD Connectでは驚くほど簡単になっています。今日は備忘録代わりに設定を載せておきます。

■　■　■

AAD Connectを使ってSSO設定を行う際(ウィザードのステップバイステップはこちらに乗せてあります)、
AAD Connectのウィザード設定で[一意のユーザー識別]というページがあるので、[ユーザープリンシパル名]としてuserPrincipalNameではなく、mailを選択するだけ。

これにより、mail属性をベースにAzure ADへディレクトリ同期が行われ、SSOもmail属性ベースで行われるようになります。
(この画面でお気づきになったと思いますが、最近AAD Connectのウィザードが日本語対応になったのですね)

また余談ですが、Synchronization Serverツールから同期された様子を見てみると、userPrincipalNameの値としてActive DirectoryユーザーのUPNではなく、メールアドレスが入っていることも確認できます。

クラウド時代は改善のスピードも桁違いですね。

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

今日はAAD Conectに関わる、ちょっとした小ネタを。

Active DirectoryとAzure ADの間で行うディレクトリ同期を担当するAzure AD Connect (AAD Connect)。
かつて、DirSyncやAADSyncなどのツールとして提供されていたAAD Connectはディレクトリ同期をActive Directoryからディレクトリ同期サーバーまでの同期を行い、ディレクトリ同期サーバーからAzure ADへの同期を(一時的に)行わないようにする、ステージングモードと呼ばれるオプションが用意されています。

これを図で表すと以下のようになります。
ディレクトリ同期は本来、Active Directoryディレクトリ同期サーバーへの同期(1.と3.の処理)、Azure ADに同期を行う前の現状確認のための同期(2.と4.の処理)を行ったのちに、Azure ADへの同期(5.の処理)を行いますが、5.のExport処理を行わないのがステージングモードです。

ステージングモードは、ディレクトリ同期サーバーとAzure ADの間の同期を実行せず、一時的に待機させておくことで、

一時的にディレクトリ同期サーバーでインターネット接続して欲しくない
Active Directoryとディレクトリ同期サーバー間の同期だけをテストしたい

などのニーズに対応するものです。
(ちょっとインパクトに欠けるニーズかな？？)

それでは、ステージングモードの実装を早速確認してみましょう。

■　■　■

まず、AAD Connectをインストールしたコンピューターはデスクトップにアイコンが作られるので、これを実行します。

すると、ウィザードで[追加のタスク]が表示されるので、ステージングモードを選択し、

Azure ADの資格情報を入力すると、ステージングモードの設定を有効または無効に切り替えられます。

ステージングモードを有効にしたディレクトリ同期サーバーはActive Directory→ディレクトリ同期サーバー、ディレクトリ同期サーバー→Azure ADの同期をそれぞれ行いますが、Azure ADへのExport処理が行われていないことがSynchronization Service管理ツールからわかります。

しかし、ディレクトリ同期サーバーにはActive DirectoryのID情報が同期されているので、Synchronization Service管理ツールで[Metaverse Search]をクリックして、検索すると、検索結果として、Active DirectoryのID情報が確認できます。

以上のことから、ステージングモードを有効にしておくことで、Active Directory→ディレクトリ同期サーバーの同期だけを行い、ディレクトリ同期サーバー→Azure ADの同期は一時停止してくれていることがわかります。

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

突然ですけど、AAD Connectのインパクトってすごいですね。

AAD Connectの登場によって、DirSync + ADFSサーバーでOffice365のシングルサインオン環境を運用している企業でも、いずれDirSyncからAAD Connectに入れ替える時が来るのではないかと思います。

私自身も、DirSyncを使ってSSO環境を運用していたのですが、AAD Connectに入れ替えようと思ったら、案外AAD Connectのウィザードが便利なので、「SSO環境を全部壊して、1から作り直したほうが楽なのでは？」と思いました。そこで、既存のサーバーからADFSを削除し、AAD Connectから再度インストールしようとしたのですが、エラーが発生してしまいました。

そうです。
Windows Server 2012 R2のADFSサーバー(ADFS3.0)は一度アンインストールして、もう一度インストールしようとすると、エラーが発生するのです。

以前のバージョンでも、再度ADFSサーバーをインストールしようとすると、エラーが発生し、日本マイクロソフトの安納さんがブログで紹介していた設定を行い、ゴミを手動で削除する必要がありました。

そして、Windows Server 2012 R2のADFSサーバーでは、安納さんが紹介していた設定に加えて、追加で必要な設定があったので、紹介しておきます。

ADFSサーバーのデータベースにSQL Serverを利用している場合には、ブログで紹介している通り、SQL Server Management Studioから残ったデータベースを削除します。

一方、WIDを利用している場合にはC:\Windows\WID\Dataフォルダーにデータベースが残るので、ファイル削除で削除します。下の図を見ればわかる通り、ADFSのデータベースはファイル名がAdfs*.*なので、関連するファイルをすべて削除してしまいましょう。

すると、ADFSサーバーの再インストールは問題なく行えるようになります。

お試しあれ。

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

今日はAzure ADに関する、ちょっとした小ネタを。

Active Directoryでは、すべてのユーザーを含むグループとして、Domain Users、Authenticated Users、Everyoneといったグループがあったかと思います。一方、Azure ADではEveryoneのようなグループが既定で用意されていません。

そのため、利用するときはAzure管理ポータルのAzure ADドメインから[構成]タブをクリックし、[専用グループの有効化]ならびに[すべてのユーザーグループの有効化]をそれぞれ[はい]にしてあげます。

すると、All Usersという名前のグループが作成され、グループの一覧を見ると、ドメイン内のすべてのユーザーが自動的に含まれていることが確認できます。

このように、Azure ADの設定で[すべてのユーザーグループの有効化]を行っておくことで、Everyone相当のグループが利用できるようになります。

余談ですが、グループの[構成]タブをクリックすると、動的メンバーシップの設定として「All Users」という条件が入っているのですね。

皆さんこんにちは。
当ブログが100万PVを超えていることに全く気が付いていなかった国井です。

先日、ADFS2.0を扱っているお客様にお会いする機会がありました。
そのお客様はADFS3.0 (Windows Server 2012 R2のADFS) にアップグレードする機会があり、ADFS3.0になるとIISを利用しなくなるので、今までとは色々な面で面倒が生じるという話をされていました。

その「面倒」のひとつに当たるのが、ADFSのサインインページのカスタマイズです。

たとえば、サインインページをカスタマイズしたい場合、ADFS2.0のときにはIISのディレクトリに保存されている各種ファイルを編集すればカスタマイズできるページもありましたが、その手法はADFS3.0では利用できません。そこで、今日はADFSのサインインページをカスタマイズする方法を紹介しておきます。

と言いたいところなのですが、実はマイクロソフトさんのWebサイトにカスタマイズ方法は紹介されています。

■AD FS サインインページのカスタマイズ
https://technet.microsoft.com/ja-jp/library/dn280950.aspx

ですので、上記サイトをご覧いただければ解決するのですが、私からは1点だけ補足しておきます。

補足事項を説明するために、ひとつカスタマイズを行ってみます。
その前にデフォルトのサインインページを確認しておきます。

確認できたら、ロゴのカスタマイズを行ってみましょう。
今回は弊社(株式会社ソフィアネットワーク)のロゴ(logo.gif)を用意してみました。

このロゴファイルをADFSサーバーのc:\toolsフォルダーに保存し(保存場所はどこでも良いです)、ADFSサーバーから以下のPowerShellコマンドレットを実行します。

Set-AdfsWebTheme -TargetName default -Logo @{path=”c:\tools\logo.gif”}

出来上がったら、サインインページにアクセスしてみましょう。

すると、いかがでしょうか？
文字で表されていた領域がロゴに変わっていることが確認できます。

■　■　■

長くなりましたが、ここからが本題です。
ADFSサーバーで設定したカスタマイズはWebアプリケーションプロキシ(ADFSプロキシ)経由でのアクセスはどうなってしまうのでしょうか？

ご心配無用です。
ADFSサーバーで設定したカスタマイズはWebアプリケーションプロキシにも引き継がれるので、Webアプリケーションプロキシで別途、同じ設定を行う必要はありません。
Webアプリケーションプロキシからのアクセスはご覧のとおり。

PowerShellからサインインページをカスタマイズするという方法はあらかじめ決められた部分しかカスタマイズできないことを意味しますが、それでも多くのオプションを用意しているので、とても多岐にわたるカスタマイズが可能です。

たとえば、ロゴで言うと、-TargetName の後ろをdefaultから特定の証明書利用者信頼の名前に変えれば、特定のサービスにアクセスするときだけ有効なロゴを表示させることもできますし、サインインページの左側の画像の変更、サインインページのメッセージ、免責事項の表示、などなどたくさんあります。
さらに、エラーページのカスタマイズだって、できちゃいます。それもエラーページ共通のメッセージではなく、エラーの種類に合わせてメッセージも変えられるので、すばらしいですね！
ちなみに、下のエラーページのカスタマイズPowerShellコマンドレットはデバイス認証に失敗したときのカスタムエラーメッセージなのですが、メッセージ文の中にHTMLタグを入れておくことも可能です。Bタグで太文字にしたり、Aタグでリンクを張ったり、Pタグで改行するなど、ここまでのことができれば、思い通りのサインインページが作れそうですね。

Set-AdfsRelyingPartyWebContent -Name “Microsoft Office 365 Identity Platform” -ErrorPageDeviceAuthenticationErrorMessage “<b>Office 365 を利用するには事前にデバイス登録が必要です。</b>”

お試しあれ！

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

これまで当ブログでは、Azure Active Directory をはじめ、Enterprise Mobility Suite (EMS) シリーズの紹介を色々としてきました。
そして、このたび当ブログの別館が Channel 9 にオープンし、最初のシリーズとして Windows 10 デバイスを Microsoft Intune で管理する方法を紹介させていただくことになりました。

■Channel 9 – Always on the clock Annex
https://channel9.msdn.com/Blogs/Always-on-the-clock-Annex-Suguru-Kunii-Microsoft-MVP-for-Identity–Access-Directory-Services

Windows 10 デバイスを Microsoft Intune で管理する方法の紹介動画は全10回のシリーズですが、第1回目は Microsoft Intune の紹介と初期設定についてです。

動画では、デモストレーションや現地中継(？)を交えて解説していますので、
モバイルデバイスとして Windows 10 を利用される方、ぜひご覧になってみてください！

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

クリエ・イルミネートさんで開催させていただいている、
Office 365ユーザー認証ベストプラクティスコースですが、
2015年11月開催分が大変申し訳ないのですが、満席となってしまいました。

3か月に一度、開催させていただいているのですが、
お客様から「3か月に一度では遅い」とお叱りを受けることもあり、
今後の開催については現在検討させていただいているところです。

今の段階でお伝えできることとしては、2016年2月17～18日の開催が
ありますので、こちらへの参加をご検討ください。
もし、どうしても早い段階で参加されたいということでしたら、
お問い合わせいただければ、特別開催なども検討しますので、
まずはお声がけいただければ幸いです。

色々とご不便をおかけしますが、今後ともどうぞよろしくお願いいたします。

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

最近、「Windows Server Active DirectoryからAzure Active Directoryに移行したいのですが」というご相談を伺うようになってきました。Azure Active DirectoryをWindows Server Active Directory的な感じで使いたいと考えた場合、ひとつの課題として出てくるのがPowerShellでADを扱いたいというテーマだと思います。もちろん、Azure Active Directory (Azure AD)にはPowerShellツールが用意されているけれど、コマンドレットで用意されていないようなことにチャレンジしたいとなると、APIレベルでのアクセスが必要となります。

Azure ADではGraph APIを利用することでAPIレベルでのAzure ADへのアクセスができますが、インフラ屋の私としてはできればVisual Studioを使わないで実現したい。
そんなときに覚えておきたいのが、PowerShellを使ってGraph APIを扱う方法です。

では、順番に見てみましょう。

■ADAL DLLファイルの取得
ここでは、PowerShellからGraph APIを扱う方法として、ADAL(Active Directory Authentication Library)を活用します(ADALそのものの説明は別の機会に)。ADALは本来Visual StudioからNuGetを使ってライブラリを取得し、Visual Studioで作成するソリューションに組み込んで利用するものなのですが、Visual Studioを使わないでADALを取得したい場合は、手動でNuGetを使って取得します。

という操作を書こうと思ったら、

Dushyantさんという方がNuGet→ADAL取得までの一連の操作をPowerShellスクリプトでまとめてくださっているので、
参考にさせていただきました。(Thank you Mr.Dushyant, you provided a useful script that we really want. I appreciate that!)

http://www.dushyantgill.com/blog/2013/12/27/aadgraphpowershell-a-powershell-client-for-windows-azure-ad-graph-api/
Load-ActiveDirectoryAuthenticationLibraryの項を参照のこと。

Load-ActiveDirectoryAuthenticationLibraryを実行し、ADALを取得すると、以下のパスにDLLファイル群が保存されます。
c:\users\<ユーザー名>\Documents\Nugets\Microsoft.IdentityModel.Clients.ActiveDirectory.2.19.208020213\lib\net45

net45フォルダーに保存されているファイル群をこの後、PowerShellから呼び出すのですが、パスが長いと面倒なので、ここではnet45フォルダーをADALと名前を変え、
c:\ADALフォルダーにファイルをすべて置くことにしました。

■Graph APIアクセスを受けるためのAzure AD アプリの作成
クライアントからGraph APIでAzure ADにアクセスする場合、アクセスを受け付けるためのアプリをAzure AD側に追加する必要があります。
このアプリはAzure管理ポータルから管理対象となるAzure ADドメインにアクセスし、[アプリケーション]から[追加]をクリックし、アプリケーションを追加します。

追加時に[組織で開発中のアプリケーションを追加]を選択すると、ウィザードが始まり、
[アプリケーション情報の指定]で適当な名前を入力します。

[アプリケーションのプロパティ]で、サインオンURLにhttp://localhostと入力し、
アプリケーションID/URIには適当なURLを入れておきます。
URIは単なる識別子なので、一意でありさえすれば、実在する必要はありません。
(ここではhttp://dc.example.com)としておきます。

アプリケーションが出来上がったら、構成タブをクリックします。
(下の画面ではロゴを変えてしまってます)

画面をスクロールしたら、まずクライアントIDが表示されるので、控えておいてください。
それから[キー]は通信をするうえで必要になるものなので、作成しておいてください。
(下の画面は作成後のものですが、作成前には作成ボタンがありますので、そちらを使います)

それから上の画面で、[他のアプリケーションに対するアクセス許可]では、Graph API経由でのアクセスを許可する範囲を定義します。以下のように設定しておけば、Azure ADのユーザー情報は少なくとも引っ張ってくることができます。(それ以上の操作が必要なときは追加でアクセス許可を与えてください)

ここまでできたら、保存してAzure AD側の設定を完了します。

■PowerShellスクリプトの作成と実行
スクリプトでは、ADALのロード、AuthenticationContextオブジェクトの作成、アクセスするテナントの指定、そして行いたい操作の順に記述していきます。
ここでは、Azure AD の監査レポート(auditEvents)を列挙する操作を行っています。

#ADALのロード
Add-Type -Path `
‘C:\ADAL\Microsoft.IdentityModel.Clients.ActiveDirectory.dll’

#AuthenticationContextオブジェクトの作成
$AuthNC=New-Object `
Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext `
-ArgumentList @(
‘https://login.windows.net/common’
$false
)

#アクセスするテナントの指定
$resource = “https://graph.windows.net”
$clientId = “<クライアントID>”
$redirectUri = [uri]”<アプリケーションのプロパティで指定したURI>”
$authenticationResult = $authenticationContext.AcquireToken`
($resource, $clientId, $redirectUri)

#Azure ADからユーザー一覧を取得
Invoke-RestMethod -Method Get -Headers @{
Authorization = $authenticationResult.CreateAuthorizationHeader()
‘Content-Type’ = “application/json”
} -Uri (‘https://graph.windows.net/{0}/`
reports/auditEvents?api-version=beta‘ `
-f $authenticationResult.TenantId)

 

以上の流れを覚えておけば、最終行の太字の部分だけ別の操作を書くことで
様々な情報をAzure ADから取得できるのです。
また、最終行の太字で書いた部分を
reports/auditEvents?api-version=beta&$filter=eventTime gt 2015-05-08 and eventTime lt 2015-05-11

と書けば条件設定も可能です。
どんなことを書けば、何が取得できるかについては機会を改めて紹介できればと思いますが、
少なくともこの流れを覚えておくと、何かと役に立つのではないでしょうか。

■参考情報ー条件設定に利用可能なプロパティ(属性)一覧
https://graph.windows.net/<Azure ADテナントのドメイン名>/$metadata

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

最近、私の周りではマイクロソフトが提供するクラウドサービス、Enterprise Mobility Suite(EMS)の話をよく聞くようになってきました。
EMSは複数のクラウドサービスから構成されていますが、そのEMSの中にあるデバイス管理ソリューションがMicrosoft Intuneと呼ばれるサービスです。
昔は「Intune」と検索すると、「もしかしてiTunes?」と検索結果が出るくらいの知名度でしたが、Windows10をはじめとするデバイス管理や、SCCMと組み合わせたデバイス管理など、モバイルデバイス管理(MDM)、モバイルアプリケーション管理(MAM)、モバイルコンテンツ管理(MCM)の分野で、頭角を現すようになってきました。

そこで、今回は日本マイクロソフトの安納さんの協力でMicrosoft Intuneを知るための動画をまとめて作成させていただきました。全部で10本の動画を作りましたが、どれも20分弱で、さっと見られるものに仕上がっていますので、ご自身の興味ある分野をピックアップしてご覧になってみてください。

では、ダイジェストをご紹介します。

第1回 Microsoft Intune の概要と Windows 10 デバイスの登録 (1)
Microsoft Intuneを使ってWindows10を管理するには、デバイスの登録作業が必要です。
その登録作業をIntuneそのものの初期設定と共に解説しています。
Intuneを使い始める方、必見です！

第2回 Microsoft Intune の概要と Windows 10 デバイスの登録 (2)
前回に引き続き、Intuneの初期設定作業を紹介しています。第1回の動画と合わせてごらんください。

第3回 特殊な Windows 10 デバイスの登録方法とインベントリ参照
Windows10デバイスをIntuneするとき、利用条件や使用許諾契約にあたるような文書を事前に提示するような登録ができるので、その方法についてデモンストレーションと共に紹介しています。

第4回 デバイスのセキュリティ ポリシーの実装
この回からは新シリーズとして、セキュリティポリシーによるデバイスに対する様々な制限設定を紹介しています。

第5回 Windows 10 カスタム ポリシー/コンプライアンス ポリシーの実装
Windows10専用のポリシー設定で様々な機能制限を設定しています。

第6回 Windows 10 デバイスのための電子メール プロファイルの配信
Intuneのポリシーは機能制限を設定するだけでなく、デバイスに対する各種設定を自動化することもできます。この回ではメールプロファイルの設定をIntuneから配布し、設定を自動化する方法を紹介しています。

第7回 条件付きアクセスによるコンテンツ アクセス制限
この回から始まる新シリーズでは、アプリケーションとコンテンツの管理機能についてです。
特に第7回では、Intuneの機能のハイライトともいうべき、セキュリティポリシーに基づくメールやコンテンツへのアクセス制限機能について紹介しています。

第8回 アプリケーション ポリシーを使用したアプリの配信
アプリケーションの配布機能を紹介しています。モバイルアプリケーションの配布機能は撮影時点でWindows10対応ではなかったので、代わりにiOSアプリの配布方法を紹介しています。

第9回 会社で保護されたアプリによるデータの保護
業務で使用するアプリで扱われるコンテンツに対するアクセス制限機能を紹介しています。
この機能、私のお気に入りで、情報漏えいを防ぐソリューションとして、こんな手があったか！と思わせてくれるものです。
ぜひご覧ください！

第10回 デバイス紛失時の対応
最終回はリモートワイプと呼ばれる、遠隔からデバイスのデータを消去する機能の紹介です。
Intuneではセレクティブワイプと呼ばれる、ちょっと特殊な方法で、業務で使用するアプリとデータだけを消すという芸当をやってのけてくれます。

■　■　■

このお話をいただいたときに、他の動画とはひと味違った、リラックスして見ていただけるものを作ろうと思い、独特な雰囲気(場所)で解説するということをしてみました。
真夏のビーチで解説してくれ！とか、温泉旅館で足湯につかりながら解説してくれ！とか無茶なリクエストもいただきましたが、いくらBYOD時代だからと言って、そんなところで仕事をすることなんかないですよね？

話は脱線してしまいましたが、楽しんで学習していただければ幸いです。

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

Office 365を導入されるお客様で、シングルサインオンも一緒に導入したいと考えるお客様は最近増えてきているように思います。と同時に、お客様からよくご相談を受けるのが「特定のデバイスからのアクセスを制限したい」ということです。

当ブログでは何回かに渡って、このテーマはお話ししていますが、ざっくり言うと、
Windows 8.1の時代にはAzure ADまたはADFSを利用したデバイス登録(DRS)と、
登録されたデバイス情報に基づくADFSサーバーによるデバイス認証機能を利用することで要件を満たしてきました。
(下の図はAzure ADを利用したDRSの仕組み)

つまり、「特定のデバイスからのアクセスを制限したい」というニーズを満たすためには、

・DRSという機能で、事前にデバイスを登録 (Azure ADまたはADFSで登録)
・デバイス認証の機能でアクセス可否を決定 (ADFSで設定)

の2つを行う必要があるのです。

このうち、今日はAzure ADでのデバイス登録の話をします。
Azure ADでのデバイス登録方法とその結果の確認方法は過去のポストでも紹介しましたが、
Azure ADからデバイス登録を行うと、デバイス登録の結果はAzure管理ポータルから確認できます。

しかし、この画面、ユーザーごとにしかデバイスの登録状況を確認できません。
しかも、デバイス登録と登録解除を繰り返すと、過去に登録されたデバイス情報が残り続けるので、ゴミが溜まっていくシステムなのです。

Azure Active Directory PowerShellモジュールの活用

そんな折、最近マイクロソフトではAzure ADをPowerShellで操作するツールの新しいバージョンをリリースしました。
Azure AD PowerShellモジュールはADAL対応により、多要素認証が利用できるようになったことがクローズアップされていますが、私が注目したいのはPowerShellコマンドレットで、Azure ADに登録されたデバイスの管理ができるようになった点です。

新しいAzure AD PowerShell モジュールでは、

Get-MSOLDeviceを使えばAzure ADに登録されているデバイスの一覧表示、
Enable-MSOLDeviceを使えばAzure ADに登録されているデバイスの有効化、
Disable-MSOLDeviceを使えばAzure ADに登録されているデバイスのブロック、
Remove-MSOLDeviceを使えばAzure ADに登録されているデバイスの削除、

をそれぞれ設定できます。

実際に利用してみた様子がこちら。

Get-MsolDevice –Allを実行すると、Azure ADに登録されている、すべてのデバイス情報が一覧で確認できます。単純にGet-MsolDevice –Allと実行してしまうと、リスト形式で表示されてしまい、見にくいので、Get-MsolDevice –All | Ft Displayname, DeviceIdなどと実行すると、見やすく整形してくれていいのと思います。その中から、特定のデバイスだけ取り出して詳細な情報を見たければ、Get-MsolDevice –DeviceId <デバイスID番号>と実行すれば、上の画面のように表示してくれます。ちなみに、Enabled：Trueというところがデバイスの有効化/ブロックに関わるステータス、RegisteredOwnersというところが、デバイスを登録したユーザーの情報です。

では、続いてデバイスの有効化/ブロックを行ってみます。

Disable-MsolDevice –DeviceId <デバイスID> -Forceを実行すると、そのデバイスはブロックの設定になります。

この情報はディレクトリ同期ツールによって、Active Directoryに送られ、ADFSサーバーでアクセス可否を決定するときの材料として利用されるようになります。

特定のユーザーが不正アクセスに遭ったので、そのユーザーのデバイスをとりあえず全部使えないようにしたいということであれば、

Get-MsolDevice –RegisteredOwnerUpn <ユーザーのUPN> |Disable-MsolDevice –Forceを実行すると、すべてのデバイスがブロックされます。

それから削除について。
デバイス登録と登録解除を繰り返すと、ゴミが残るといいましたが、これもGet-MsolDeviceで発見して、Remove-MsolDeviceで削除すればいいのです。

Get-MsolDevice –RegisteredOwnerUpn <ユーザーのUPN>| Ft Displayname, DeviceId,ApproximateLastLogonTimestampと実行し、タイムスタンプが古いものを見つけてきて、Remove-MsolDeviceで削除しています。
(ApproximateLastLogonTimestamp属性はサインインの日時ではないようなのですが、詳細はわかりません。。)

いかがですか？Azure管理ポータルから操作するよりも、まとめて操作しやすい環境が整ったと思いませんか？
(本当はAzure ADだけでデバイス認証もできるようになってくれると、もっとうれしいんだけど）

■　■　■

今日の最後のトピックは、「Windows 10デバイスはWindows8.1と同じようにデバイス認証ができるか？」という点です。
まず、結論から先に言うと、私が検証している限りでは、ADFSのデバイス認証でWindows10のアクセス制御ができないようです。
(このことについては山市さんのブログでも紹介されています)

簡単に引っかかっているポイントをお話しすると、
ADFSのデバイス認証では、ADFSサーバーがトークンを発行するタイミングで
ユーザーがあらかじめ登録されたデバイスからアクセスしているかをチェックし、
登録されたデバイスからのアクセスであれば、isRegisteredUserというクレームにTrueという値を入れ、
そしてisRegisteredUser=TrueならADFSとしてトークンを発行することを許可しましょう(アクセスを許可しましょう)、という流れです。

実際に、このとおりの動きになるのか見てみると、Windows 8.1ではisRegisteredUser=Trueというクレームが発行されるのですが、
Windows 10ではisRegisteredUserクレーム自体、全く発行されません。
デバイス登録自体は問題なくできているし、登録されたデバイス情報のディレクトリ同期もWindows8.1を同じ情報を同期できているので(下記、おまけ参考)、ADFSサーバー側の処理の問題でWindows10にisRegisteredUserクレームが発行されず、デバイス認証がうまく動作しないようです。

結構これってニーズが高いので、何か回避策を早いところ見つけたいものですね。

■　■　■

おまけ – Azure ADのDRSで登録されたデバイスはADにどのような属性が同期されるか？
Windows 10デバイスがADFSでデバイス認証できないのはディレクトリ同期で同期される属性に違いがあるからなのかと思い、
ディレクトリ同期の結果をチェックしてみた結果は以下のとおりです。結果は「違いなし」です。

■Windows 10デバイス(Azure AD参加済み)をAzure AD から同期した時の結果

■Windows 8.1デバイス(ドメイン参加済み＋Workplace Join)をAzure AD から同期した時の結果

■Windows 8.1デバイス(ワークグループ＋Workplace Join)をAzure AD から同期した時の結果

ドメイン参加しているPCの場合、isManaged=Trueになるという結果以外は、OS種類による違いは特にないようです。

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

今日はADFSのデバイス認証機能のトラブルシューティングについて。

ADFSでデバイス登録/認証機能を利用するとき、

Initialize-AdfsDeviceRegistration
Enable-AdfsDeviceRegistration

の2つのPowerShellコマンドレットを実行していました。詳しくはこちらを参照。

ところが先日、私の環境で設定していたら、こんなエラーが。
「Device Registration ServiceのACLを構成できません。」

Enable-AdfsDeviceRegistration の実行に失敗する場合、ACLのエラーであれば、RegisteredDevicesコンテナーにサービスアカウントに対するアクセス許可が割り当てられていないことが原因です。

その時は、ADSIエディターを開き、構成パーティション(既知の名前付けコンテキスト：構成)に接続し、CN=DeviceRegistrationService,CN=Device Registration Service,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=xxxxx のプロパティを開いて、サービスアカウントにフルコントロールのアクセス許可を割り当ててあげます。

理論上は以上の手順でエラーが解消され、コマンドレットが実行できるようになるのですが、
私のケースでは複数回Initialize-AdfsDeviceRegistration とEnable-AdfsDeviceRegistration を実行することで解決しました。(なぜ？)

参考になれば幸いです。

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

以前、特定のデバイスからのアクセスのみADFS経由でのアクセスを許可するデバイス認証の話をしましたが、デバイス認証には事前にデバイス登録(Device Registration Service：DRS)をしておく必要があります。
そして、そのデバイス登録をAzure AD経由で行った場合、Azure ADからオンプレミスのActive Directoryへディレクトリ同期する必要があります。

既にOffice 365のシングルサインオン環境を構築している企業では、ディレクトリ同期にDirSyncを利用しているところも多いかと思いますが、今後、AAD Connectに切り替わっていくことも予想されます。
そして、登録されたデバイスのディレクトリ同期に関わる設定はDirSyncとAAD Connectでは異なるので、今日はAAD Connectでの設定方法を確認してみたいと思います。

■　■　■

DirSync での登録デバイスのディレクトリ同期は以下のようなコマンドレットを実行していました。

Import-Module DirSync
$ADCred=Get-Credential

$AADCred=Get-Credential

Enable-MSOnlineObjectManagement –ObjectTypes Device `
–Credential $ADCred –TargetCredential $AADCred

一方、AAD Connectでは、上記のコマンドレットの代わりにAAD Connectのインストールウィザードで登録デバイスを同期するようにチェックボックスにチェックを入れるだけです。
(その他の作業は以前の投稿で確認してくださいね)

ところが、ウィザードを見てみると、チェックボックスにチェックをつけられない！
([デバイスの書き戻し]という欄です)

初めて実行するときには少し焦るのですが、そこは慌てずに一度ウィザードを完了させてしまい、その後PowerShellコマンドレットから以下のコマンドレットを実行してください。

Install-WindowsFeature –Name AD-DOMAIN-Services –IncludeManagementTools

Import-module ‘c:\Program Files\Microsoft Azure Active Directory Connect\Adprep\AdSyncPrep.psm1’

Initialize-ADSyncDeviceWriteBack –domainname <domain.com> –AdConnectorAccount <ドメイン管理者のUPN>

実行したら、デスクトップに作成されるAAD Connectのアイコンを実行して、ウィザードを起動し、追加のタスクから[同期オプションのカスタマイズ]を選択して、

ウィザードに沿って進めていくと、

ご覧のとおり、[デバイスの書き戻し]にチェックがつけられるようになります。

これから先、DirSyncからAAD Connectへの移行案件が出てくることが予想されますが、そのときに慌てないように今からAAD Connectについて、しっかり準備しておきたいものですね。

皆さんこんにちは。国井です。
クリエ・イルミネートさんと協業で開催させていただいている、
Office 365ユーザー認証ベストプラクティスコースの年内最後の開催が昨日終了しました。

現在予定している開催(～2016年3月)はすべて満席となっており、お申し込みいただけない状態となっております。ですが、リクエストベースで開催をさせていただくことも可能なので、受講を希望される方は大変お手数ではございますが、直接お問い合わせいただけますでしょうか？
2016年4月以降はAzure Active Directoryをはじめとするテクノロジーの変化に対応すべく、3日間でのトレーニングコースの開催を予定しております。詳細については決まりましたら、改めてご案内させていただきますので、今後ともどうぞよろしくお願いいたします。

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

もう12月ですか、1年が過ぎるのもあっと言う間ですね、
などと年寄りじみたことを考えるこの頃です。

今日はオンラインイベントの紹介です。

12月16日20:00から
Azure Active Directoryをまとめてご紹介しようというイベント、
Windows 10 IT Pro Readiness (JPN) –
Sub session <Introduction of Azure Active Directory>
が開催され、
Microsoft MVPの宮川麻里さんと共にお話をさせていただくことになりました。

オンラインイベントなので、お好きな場所から参加し、聞いていただけるので、
お時間の許す方はぜひご参加ください。
いつもはブログで一方的に情報発信するばかりですが、
当日は質問コーナーなども設けていますので、
インタラクティブなディスカッションができるのでは？と思っています。

ご参加いただく場合は、事前に参加登録が必要ですので、
下記サイトから登録をお願いします。

https://mvp.eventbuilder.com/event?eventid=w4r4x0

夜遅い時間で恐縮ですが、ご参加お待ちしています。
あ、あと、ビールとつまみもお忘れなく(笑)

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

2015年を振り返るには少しだけ早いけど、私が今年、最も多く受けたご質問は間違くなく

「Azure Active DirectoryとActive Directoryは何が違うのか？」

です。

Active Directoryはオンプレミスのリソースに対する認証基盤、
Azure Active Directoryはクラウドのリソースに対する認証基盤なので、

用途が異なりますし、そこで求められる要件・機能も違うはずです。
だから私個人の考えでは、比較すること自体、ナンセンスだと思っています。

■　■　■

例えば、Active Directoryの「信頼関係」について考えてましょう。
オンプレミスのActive Directoryにおける、信頼関係とは、
同じ社内ネットワークでつながっている、複数のActive Directoryフォレスト(またはドメイン)を結びつけるものでした。これって、ざっくり言ってしまえば、信頼関係を結ぶドメインどうしの相互接続を「全許可」するものです。

だけど、これをクラウドに置き換えてみたら、どうでしょうか？
Azure Active Directory(Azure AD)の信頼関係って、オンプレミスのActive Directoryと全く同じ機能を必要とするでしょうか？
事実、Azure ADには「同じ社内ネットワーク」という考え方自体が存在しないですし、
これだけビジネスのスタイルが多様化している中で、2つの会社のディレクトリを相互に「全許可」するやり方だなんて、時代にマッチした実装ではないのでは？と思うのです。

ですので、Azure ADで他のディレクトリとの相互運用を考えるのであれば、
盲目的に「Active Directoryにあった信頼関係って、Azure ADではどうやって設定するの？」と考えるのではなく、

自社のAzure ADを使ってもらいたい外部のユーザーが誰か？
自社のAzure ADを経由してアクセスさせたいアプリは何か？

を再定義し、それに合わせて必要な設定をAzure ADに実装するべきなのです。
その辺りを意識した、Azure ADのおける信頼関係機能がAzure AD B2Bと呼ばれる機能です。

では、(前置きが長くなりましたが)実装方法を見てみましょう。

■　■　■

Azure AD B2Bを利用した信頼関係では、Active Directoryの信頼関係のように、2つのディレクトリ(ドメイン)全体を結びつけるのではなく、

外部のAzure ADユーザーと自社のドメインからアクセス可能なアプリケーションを

関連付ける形で設定します。

こうすることで、外部のユーザーに対して自社のAzure ADドメインを利用させるけど、その範囲は最小限に抑えることができます。

しかも、他のドメインにあるユーザーと同じ名前のユーザーを自分のドメインに作成するのと違って、自社に作られる外部ユーザーはあくまでも「ショートカット」に過ぎないので、
大元のユーザーが削除されればアプリケーションへのアクセス許可も失われます。
つまり、ID管理が一元化されるので、複数箇所に混在する退職者アカウントがいつまでも残り続けるリスクを避けることができるのです。

以上の概要を見てみると、Azure ADの信頼関係設定で必要なことは、
どのユーザーに対して、どのアプリケーションに対するアクセス許可を設定するか、定義することだということがわかりますね。

それを踏まえて設定をしていきますが、
設定はCSVファイルを使って行います。

CSVファイル自体の設定はMSさんのサイトでも紹介されておりますので、

■Azure Active Directory (Azure AD) の B2B コラボレーション
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-b2b-collaboration-overview/

を参考にしていただけるとよいと思います。

少しだけ補足すると、CSVファイルの形式で属性を指定するのですが、
以下の属性が必須の属性になります。
Email：招待されるユーザーの電子メールアドレス (Azure ADのユーザー名)
DisplayName：Azure AD に表示されるユーザーの表示名
InviteContactUsUrl：お問い合わせ先URL (後に登場する招待状メールで使われるそうなのですが、確認できませんでした。なので、ここでは適当なURLを指定します)

あと、以下の属性は必須ではないですが、今回は使う予定です。
InviteAppID：アクセスするアプリケーションのアプリケーションID
InviteAppResources：アクセスするアプリケーションのアプリケーションID
InviteGroupResources：招待されるユーザーが所属する自社Azure ADドメインのグループ (グループのオブジェクトIDで指定)
Language：招待状メールで使う言語 (jaと書けば日本語になります)

このうち、アプリケーションIDはAzure AD PowerShellから

Get-MsolServicePrincipal | fl DisplayName, AppPrincipalId

と書いて実行すれば、アプリケーションIDは次のように確認できます。
今回はOneDriveにアクセスできるようにしてみたいと思います。

それから、グループのオブジェクトIDですが、こちらもAzure AD PowerShellから

Get-MsolGroup

と書いて実行すれば、オブジェクトIDは次のように確認できます。
ここでは、Salesグループに招待されたユーザーが含まれるようにしてみたいと思います。

以上を踏まえて、以下のようなCSVファイルを作ってみました。

では始めましょう。

Azure管理ポータルから、Azure ADドメインのユーザーを作成し、

ユーザー種類として、パートナー会社のユーザーを選択し、前に作成したCSVファイルを指定します。

登録完了すると、結果はレポートで確認することもできます。

ここではレポートを後回しにして、先を急ぎましょう。
ユーザーを作成すると、招待されたユーザーにはメールが1通届きます。

リンクをクリックすると、Webページに飛ばされ、

承諾すると、アプリケーションパネルWebサイトに移動し、OneDriveが利用できるようになります。

アプリケーションパネルでちょっとトリッキーなのが、画面右上の部分で、
Azure ADのテナント名をクリックすると、ドロップダウンでテナント名一覧が表示され、
どのテナントを選択するかによって、利用可能なアプリケーション一覧が変わる点です。

今設定したOneDriveは、信頼関係のあるテナントをリストから選んでいる時だけ有効で、自分のテナントを選択してしまうと消えてしまうので注意が必要です。

一方、Azure管理ポータルでは追加したユーザーが参照できます。信頼関係のある、他のAzure ADドメインのユーザーは
<メールアドレス>#EXT#@<自社のドメイン名>という形式のユーザーになります。

利用するには少し慣れが必要だと思いますが、なかなか素敵な機能だと思いますよ。

お試しあれ。

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

2015年最後の投稿はお詫びです。

2015年2月に新しいサイトでのブログをスタートさせてから、
コンタクトフォームに数々のお問い合わせをいただいておりましたが、
私のところで確認できていないお問い合わせがありました。

本当に申し訳ないです！

中にはトレーニングのご依頼などもあり、
お役に立てることができず、申し訳ない気持ちでいっぱいです。

ご連絡いただいた方には、遅まきながら直接返信させていただきますので、
もう少しだけお待ちください。

サイト運営の不備で終わってしまう2015年ではありますが、
どうぞ2016年もお付き合いいただければ幸いです。

それでは、よいお年を！

国井

皆さんこんにちは。国井です。
当ブログでは毎年最初の投稿で最も読まれた投稿ランキングを紹介しているのですが、
今日はその2015年版をご紹介します。

第1位 【101シリーズ】パフォーマンスモニタ徹底攻略 ～ パフォーマンスの確認編
昨年に引き続き第1位を獲得した、この投稿はWindows Serverにあるパフォーマンスモニタの活用方法を解説したものです。パフォーマンスモニタって、ユーザーインターフェイスの解説は方々で見かけるのですが、表示された内容をどう分析するか？ということになると、極端に情報が少ないんですよね。そんなことがきっかけとなって書いたのがこちらの投稿です。同じ理由でイベントビューアとかも情報が少ないんですよね。今年はイベントビューアの話もどこかでできたらと思っています。(ADFSにも関わってくる話ですし)

第2位 忘れたAdministratorパスワードを変更する方法
正直、もうこの話したくないんですよね。
でも「Administrator パスワード 忘れ」みたいな検索ワードで流入してくるケースが後を絶ちません。

第3位 ADFSとは？フェデレーションとは？を知る方法
ADFS、フェデレーション、などなど、ID連携の話になると必ず出てくる概念をゆるーく解説したものです。
もうちょっとカチっとした説明が欲しいという人も多かったと推測していますが、
詳細をブログで説明することの難しさを近年実感している次第です。

第4位 【101シリーズ】パフォーマンスモニタ徹底攻略 ～ 基礎編
第1位で登場した内容の第1弾となる解説記事です。

第5位 Office 365にADFSが必要な理由
ディレクトリ同期ツールがあるんだったら、ADFSによるシングルサインオンなんか要らないんじゃない？という質問はよくいただきます。こうした質問に答えているのが、この投稿です。
ちなみに、最近だとHybrid Identityと言われるアーキテクチャに基づくメリットも訴求ポイントになりそうです。今年はそのことについて、どこかでその投稿を書きますね。

というわけで、ランキング結果は2014年と何も変わっていませんでした。
ただ、第6位「もうひとつのID連携 ～ Microsoft Azure Active Directoryとは？」、第7位「ADFSでデバイス認証を実装」と、ADFSやAzure ADに関する、もう少し突っ込んだところに対するニーズの高まりを感じます。

今年はWindows Server 2016が登場しますのでADFSの変化や、Azure Active Directoryの飛躍、それとデバイス面からのアクセス制御方法としてのMicrosoft Intune、この3点を中心にブログで扱えたらと考えています。
(あと、書き途中の投稿も実は64個！もあるので、それも日の目を見させてあげたいですね)

2016年もどうぞよろしくお願いいたします。