[Azure AD]AAD Connect Health for AD DSでオンプレミスのADを監視する

こんにちは、富士榮です。

Azure Active Directory（Azure AD）やPing ONEをはじめとしたクラウド上のID基盤（IDaaS）が流行ってきていますが、どのソリューションも現状はオンプレミスにActive Directoryが存在していることを前提として構成が組み立てられています。

これは、2014年のVittorio Bertocci氏へのインタビューでもオンプレミスのActive Directoryの普及率は95%を超えている、という発言があるとおり、エンタープライズ分野へIDaaSを適用する際は既存のActive Directoryを避けて通れず、どのようにシームレスにオンプレミスからクラウドへ橋渡しをするか？がフォーカスされているため決して不自然なことではありません。

しかし、こうなってくるとクラウド側の基盤がグローバルでレプリケーションされていて高い可用性を持っていたとしても、システム全体を見た時にはオンプレミスのActive Directoryがボトルネックや障害発生ポイントとなってしまいます。

と、いうことでマイクロソフトはハイブリッドID基盤をなるべく一か所で監視・管理できるようにしたり、セキュアに運用できるように色々と関連ソリューションを出しています。

脅威／リスク	対象	ソリューション
稼働状況監視	AD FS	Azure AD Connect Health for AD FS
	AD DS	Azure AD Connect Health for AD FS
不正アクセス検知	AD DS	Advanced Threat Analytics
特権ID管理	AD DS	Microsoft Identity Manager 2016

今回は、新たにPublic Previewが公開されたAzure AD Connect HealthによるActive Directory（AD DS）の稼働状況のモニタリングについて見てみたいと思います。

　公式Blogでの発表
　Introducing #AzureAD Connect Health for Windows Server AD
　https://blogs.technet.microsoft.com/enterprisemobility/2016/07/19/introducing-azuread-connect-health-for-windows-server-ad/


仕組みとしては、監視用のエージェントをAzure PortalのAzure AD Connect HealthからダウンロードしてオンプレミスのAD DSサーバへインストール・構成するだけなので非常に簡単です。

◆エージェントを入手する

新ポータル（https://portal.azure.com）のダッシュボードにAzure AD Connect Healthがない人は追加しておきましょう。

Azure AD Connect Healthを開くとAgent for AD DSのダウンロードができるようになっていますので、Get toolsをクリックしてAgentモジュールをダウンロードします。

◆エージェントをインストールする

次は、監視対象のドメインコントローラへログインしてモジュールをインストールします。
ダウンロードしたモジュールをドメインコントローラへコピーしてインストーラを実行します。

この際、以下の前提事項があるので準備をしておいてください。。

• ドメインコントローラ上でビルトインアカウントによるInternet Exploreが実行できること
• microsoftonline.com、microsoftonline-p.com、micorosoft.com、windows.netのCookieを受け入れる設定になっていること（windows.netはいらないかも）
• Azure ADテナント上でグローバル管理者権限を持つ組織アカウント（マイクロソフトアカウントではなく）が存在していること
• ドメインコントーローラからAzureへの上り通信がブロックされていないこと

特に、Windows Server 2016では、IEの設定が厳しいのでCookieの受け入れの設定を確実にしておかないとエージェントのセットアップに失敗します。


ダウンロードしたファイルを実行すると、インストールが始まります。

インストール自体は非常にシンプルなのですぐに終わります。

◆エージェントを構成する

インストールが完了したらAzure ADのテナントへ接続し、エージェントを登録します。

うまくIEの構成がされていれば、Azure ADへのログインダイアログが起動してきますので、「組織アカウント」でログインします。（マイクロソフトアカウントだとエラーが出ます）

以下、エラーになった場合のメッセージです。
＜Cookieの受け入れ設定が出来ていない場合＞

＜マイクロソフトアカウントでログインした場合＞

うまく構成ができると、以下のメッセージが出ます。

◆ポータルより状態を監視する
インストールが完了するとドメインコントローラに関する情報がエージェントによりAzure AD Connect Healthへアップロードされます。

各種状態を確認することが出来ます。
＜FSMO、サイト、GCなど＞

＜機能レベルなどのプロパティ＞

＜認証要求数、レプリケーションステータスなど＞

ちなみに監視対象のドメインコントローラを停止すると以下のようにアラートが表示されます。
（検知するまでにしばらく時間がかかります）

これでHybrid ID基盤のオンプレミス側の構成要素であるAD DSの状態監視もクラウドから実行できますので、別途監視ツールや運用ツールを用意する必要性がぐっと下がりますので、安心して基盤の運用ができますね。

MVP Renewal 7th!!

こんにちは、富士榮です。

早いもので、ついに7年目に突入しました。
（ということはこのブログも、もうすぐ9年目に・・・）

先日のMVP Program Updateを受けて、今回からはEnterprise Mobilityという分野での受賞となりました。（Identity and AccessはEnterprise Mobilityへ属することになりました）

実は昨年夏のMicrosoft Identity Manager 2016（MIM）のリリースを前にForefront Identity Manager（FIM）のカテゴリはDirectory Servicesと統合されたので、2015年7月からはDirectory Services（DS）に変わっていたんですが、あっという間に分野の再編が行われてしましました。。。

思えば最初に受賞した時はIdentity Lifecycle Manager（ILM）、すぐにFIMへ名称変更、そしてDSからEnterprise Mobility、、と7年間でここまでカテゴリ名が変わった人もいないんじゃないか？と思う程に名前が変わっていますね。。。


昨年は仕事の面でもアイデンティティ（特にIDaaS）に特化した年でしたし、@ITや日経ネットワークなどの各種媒体にIDaaS（Identity as a Service）に関する記事を公開したり、ID&IT Management ConferenceやOpenID Summit Tokyo、Asia MVP/RD Meetupをはじめとした各種イベントでの登壇の機会を数多く頂いた年でした。

今年もIDaaSに関するこの活動はしばらく続く見込みなので、今年こそ日本における「IDaaS元年！」を目指して活動を継続していきたいと思います。

皆さま引き続きよろしくお願いいたします！！

[Azure AD]Cloud App DiscoveryでシャドーITを検知する

こんにちは、富士榮です。

最近の企業の情報システム部門を見ていると、事業部門が使う業務アプリケーションについて、
・セキュリティを担保した上で使ってもらいたい
・そのためには何を使っているのかを把握し統制を効かせたい
・ただ、全部のアプリケーションを情報システム部門で管理する人的リソースがない
という状態になっているように感じます。
その結果として、いわゆる「シャドーIT」とか「野良IT」と言われる各事業部門側が個別にSaaSアプリケーションなどを契約し使っている状態が散見される状態となっている訳です。

本来はIDaaSなどをうまく活用して各SaaSアプリケーションのID部分だけでも情報システム部門で抑え込んでせめて退職済みアカウントでは使えない状態にする、などの統制を効かせる工夫をしたいところですが、すでに利用が始まってしまっているシャドーITの状態を把握するのは大企業になればなるほど困難になります。

※IDaaSの概要と情報システム部門での活用については先日始まった@ITの連載をご覧ください。
　企業のID管理／シングルサインオンの新しい選択肢「IDaaS」の活用：
　　第1回　もはや企業のID管理で避けては通れない「IDaaS」とは？
　　http://www.atmarkit.co.jp/ait/articles/1508/07/news034.html


と、いうことで今回はすでに業務部門に広まってしまったSaaSアプリケーション利用の状態を把握するために用意されているAzure ADの追加機能「Cloud App Discovery」について解説します。

◆Cloud App Discoveryとは

先に書いた通り、企業内からどのようなSaaSアプリケーションが実際に使われているのかを検出するためのツールで、Azure AD Premiumのライセンスが割り当てられている管理者が機能を使うことが出来ます。

仕組みとしては、組織内のコンピュータにCloud App Discovery用のエージェントをセットアップし、各コンピュータからのSaaSアプリケーションの利用状況をAzure ADに集める、という構成になっています。※エージェントモジュールは各Azure AD/Cloud App Discoveryテナント毎に証明書とセットでダウンロードされるので、System Centerやグループポリシーなどのクライアント構成ツールで各コンピュータに配布します。

※サービス解説ページより


◆Cloud App Discoveryの有効化

Azure Portalのマーケットプレイスより追加します。Azure Portalのマーケットプレイスを開くと「セキュリティ＋ID」のセクションに「Azure AD Cloud App Discovery」があるので選択して作成します。

◆Cloud App Discoveryの設定：コンピュータへのエージェント導入

先にも書いた通り、通常はSCCMなどでモジュールを配布することになると思いますが、今回は手動でインストールしてみます。
Azure PortalからCloud App Discovery、クイックスタートを開くと「エージェントのダウンロード」というセクションがあり、ここからエージェントモジュールをダウンロードできます。現段階ではWindows 7以降のコンピュータに対応しているようです。

ダウンロードしたモジュールを解答し、セットアップファイルを実行するとGUIモードでエージェントをインストールできます。特に設定オプションはないのでそのままインストールします。

インストール後、PCのサービスの状態を見ると[SerresEndpointAgent]というサービスが動いていることがわかります。これがエージェントモジュールの実体です。

あとは放っておけばAzure AD上にクライアントが利用したSaaSアプリケーションの情報が集まってくるはずです。


◆Cloud App Discoveryの設定：収集対象アプリケーションの絞り込み

当然このままでも良いのですが、ある程度収集対象とするアプリケーションの種類を絞り込みたい場合もありますので、ポータル側で収集対象アプリケーションの絞り込み設定を行うことができます。

[設定]から[データコレクション]のセクションを開くと対象のアプリケーションの絞り込み設定を行うことが出来ます。
既定では2,100程度のアプリケーションが選択された状態になっていますので、必要なアプリケーションのみに絞り込むことが可能です。

◆収集結果の分析

ある程度データが集まるとCloud App Discovery上のグラフに、
・アプリケーションの利用数
・ユーザ数
・エージェントの導入数
が表示されてきます。

それぞれを展開するとどのようなアプリケーションを使ったのか、誰が使ったのか、どのコンピュータにエージェントが導入されているのかがわかります。

◆非管理対象のアプリケーションをAzure ADで管理する

アプリケーションの利用情報が収集できたら、管理対象にしたいアプリケーションを選択するとAzure ADのアプリケーション管理メニューへ移動できるので、事業部門へアナウンスし、アプリケーションとの連携設定を行い、あとはAzure ADを経由して使ってもらえば、通常のアプリケーションと同様にAzure ADのレポーティングで利用状況のモニタリングが可能になります。

最初からAzure ADなどのIDaaSを使ってすべてのアプリケーションを利用する、というように統制が効かせられる環境であれば特にこのような工夫は必要にはなりませんが、なかなかそのような状況はないと思いますので、まずはこのような形で利用実態を把握するところから始めるのが良いのかもしれません。

ID&IT Management Conference 2014が開催されます

本日と明後日、東京と大阪それぞれで今年もID & IT Management Conferenceが開催されます。

　http://nosurrender.jp/idit2014/

昨年はJNSAのアイデンティティ管理WGとしてID管理システム導入時の要求定義のポイントについてパネルディスカッションを担当させてもらいましたが、今年は標準化が熱い！ということでグローバルスタンダードについてのパネルに出演させていただきます。

特に昨年～今年はOAuth2.0のRFC化やOpenID Connectの正式リリースなどアイデンティティに関する標準化に伴い、Microsoft Azure ADやSalesforce.com Identity、Ping IdentityのPing Oneなどの主要なIDaaS（Identity as a Service）ベンダが相次いで標準をサポートした年でした。
ただ、実際の導入の現場では標準かどうか？よりも各社に固有の事情に対応することの方が当然優先されるわけで、中々標準に目が行くことはありません。ということでSIer目線でID管理プロジェクトの現場ではどんなことを考えているか？という話をしようと思います。

　※ちなみに昨年度の話はこちら


当日になってしまいましたが、お手隙の人は是非いらしてください。

私も午後から大阪へ向かいます...orz　）某所のホテルの部屋にて。。

[AAD/ASP.NET] OpenID Connectを使ってAADでログオンする

先日の#idcon vol.18でAzure Active Directory(AAD)のOpenID Connect対応について話をしました。
遅ればせながらフォローアップをしていきたいと思います。

当日の資料はこちらです。

Ad（microsoftの方）のOpenId Connect対応 from Naohiro Fujie

概要としては、OpenID Connectに対応（Preview）したAADに対して、こちらもPreview公開されたOWINのOpenID Connectセキュリティ・ミドルウェアを使ってASP.NETのMVC5のWebアプリケーションで接続（ログイン）してみる、ということをやってみます。
また、その過程でAADのOpenID Connect対応の特異点となっているresponse_modeパラメータの動きについても解説していきます。

少々長くなりそうなので、

• 今回）素直にOWIN/OpenID ConnectでAADを使ってログオンする方法
• 次回）一般的なOpenID Connect OPが対応しているresponse_mode="fragment"の場合に必要な工夫

という2回でお伝えしていきます。
また、その後になると思いますが、AAD以外のOpenID Connect OPへOWIN/OpenID Connectを使って接続する例についても解説していければと思います。


■設定方法と基本的な動作
一旦、基本的な設定と動作について確認していきます。中身のプロトコルの解説を細かくする前にまずは動きをつかんでもらうことが目的です。

◇Webアプリケーションの作成（ASP.NET MVC5）
・Visual Studioを起動し、ASP.NET/MVC5のWebアプリケーションを新規に作成します。

・NuGetを使いMicrosoft.Owin.Security.OpenIdConnectをインストールします。
　現状プレビュー版のパッケージなのでリリース前のパッケージを含めて、「openidconnect」で検索すると出てきます。

・SSLを有効にします。
　これはAADに設定するアプリケーションにはHTTPSが必須なため必要な設定です。
　ソリューションエクスプローラでプロジェクトのプロパティを開き、[SSL有効]をTrueに設定します。結果、自動的にSSLのURLが生成されます。

　次に、メニューより[プロジェクト]を選び[プロパティ]を開き、WebメニューからプロジェクトのURLを先ほど割り当てられたSSLのURLを設定し、保存します。

◇AADにアプリケーションの登録
・AADの管理画面へアクセスしアプリケーションの新規作成を行います。
　以下の設定を行います。
　・実行する作業：組織で開発中のアプリケーションを追加

　・アプリケーション情報　　名前：任意
　　種類：WEBアプリケーションやWEB API

　・アプリケーションのプロパティ　　サインオンURL：先ほどVisual Studioで作成したアプリケーションのURL（HTTPS）
　　アプリケーションID/URI：任意（テナント内で一意）

　作成が完了したら構成メニューより割り当てられたクライアントIDをコピーしておきます。

◇Webアプリケーションの実装
・コードを書きます。
　ソリューションエクスプローラから、App_Start\Startup.Auth.csを開き、以下を追記します。
　usingディレクティブ

using Microsoft.Owin.Security.OpenIdConnect;

　Startupクラス

app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions()
{
   Client_Id = "AADに登録したアプリケーションのクライアントID",
   Authority = "https://login.windows.net/テナント名.onmicrosoft.com",
   Description = new Microsoft.Owin.Security.AuthenticationDescription()
   {
      Caption = "Azure Active Directory",
      AuthenticationType = OpenIdConnectAuthenticationDefaults.AuthenticationType
   }
});

　以上で準備は完了です。

◇Webアプリケーションの実行
・F5を押してアプリケーションを実行するとASP.NET MVC5のアプリケーションが起動しますので、右上のログインをクリックします。

・ログイン画面に遷移するので、右側に表示される[OpenIdConnect]をクリックします。

・AADのログイン画面に遷移するので組織のアカウントでログインします。

・ASP.NETアプリケーションにアカウントが存在しないので関連付けを行います。

　ちなみにこのアカウントはAspNetUsersテーブルに格納されますので、サーバエクスプローラから確認・編集ができます。

・ログインが完了し、ユーザ名が表示されます。

以上がとりあえず動くところまで、の手順です。
少ないコード量で実現できることがわかります。



■内部での通信シーケンスの解説
では、内部の動作について確認してみます。
細かく解説すると非常に面倒なフローなので、ざっくり解説すると以下の様になっています。

1. AADの認可エンドポイントがws-federationのRPになっている
2. 認証に関してはws-federationのSTSになっているhttps://login.microsoftonline.comで行われる（Federationされている）
3. 認証が完了するとcodeとid_tokenが払い出される
4. codeとid_tokenはUserAgent（ブラウザ）を経由し、HTTP POSTでclient（Webアプリケーション）へ渡される

この4番目のcodeやid_tokenのクライアントへの渡し方がOpenID Connectのresponse_modeというパラメータで決まってくるのですが、この流れを見るとAAD/OWINではform_postというタイプを使っていることがわかります。この部分がAADの特徴的な部分となっているので後ほど解説します。

以下が通信シーケンスの全体像です。

■response_modeとは
OpenID Connectの仕様を見ると本パラメータは以下の様に定義されています。

OPTIONAL. Authorization Endpoint からパラメータを返すために Authorization Server が使用する方法を通知する. 要求されるレスポンスモードがレスポンスタイプで指定されるデフォルトモードである場合, このパラメータの使用は推奨されない (NOT RECOMMENDED).

参考）http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html


OpenID Connectにおいて、id_tokenをクライアント（Webアプリケーション）へ渡す方法は、Authorization Codeフローではcodeと引き換えにresponse bodyで、Implicitフローではフラグメント（URLの後の#以下）でというのが標準的？です。
しかし、先の通信シーケンスをみるとわかるようにAAD/OWINではid_tokenをJavaScriptで自動的にクライアントへPOSTするようなフォームを含むHTMLをUserAgentへ返すことで、id_tokenをクライアントへ渡しています。この方法（response_mode）をform_postと呼びます。
現状、AADにおけるresponse_modeはこのデフォルトのform_postおよびfragment（Implicitで使われる）およびquery（GETパラメータで渡す）の3つがサポートされます。
一般的にサーバサイドでパラメータの横取りをすることが出来ないfragmentを使ってtokenを渡すのが基本なのですがOAuthにおけるaccess_tokenのようにBearer Token（トークンを持っている人なら認可する）ではなくHok Token（トークンを持っている人が本当に持ち主なのかを確認してから認可する）であるOpenID Connectのid_tokenならそこまで気を遣わなくても大丈夫、という考え方なのかも知れません。
また、これは#idconでも話したように推測でしかないのですが、これまでASP.NETがサポートしてきたws-federationやSAML-Pなどのプロトコルと同じ動きをさせることでミドルウェアの実装を簡素化する、というのが真相なのかも知れません。（ws-federationやSAML-PではSAMLトークンをUserAgentを経由してRPへPOSTして渡すのが最近の主流なので）


ただ、現在のOWINの実装では他のOpenID Connect OP（現状あまりresponse_mode自体をサポートしているOPが少なく、かつform_postをサポートしているところはほぼない）との相互接続に問題が起きやすいので、response_mode="fragment"で構成されたOPをASP.NET/OWINで使う場合にどうすれば良いのか、について次回解説したいと思います。

[JICS]Vittorio Bertocci氏へのインタビュー／オフショット

Japan Identity and Cloud Summit(JICS)で来日していたVittorio Bertocci氏にWindows Azure Active Directory(WAAD)のインタビュー記事が先週頭にBuild Insiderで公開されました。

Vittorio Bertocci氏インタビュー
　開発者にとってのWindows Azure Active Directoryの役割と今後の展開
　http://www.buildinsider.net/enterprise/interviewvittorio/01


内容は記事をご覧いただくとして、編集の方に許可を頂いたのでインタビュー中の写真を少々アップしておきます。

JICSの講師控室でインタビューしていました。占有してしまって済みませんでした。
しかし事前に質問を用意していたとはいえ、全編英語でのインタビューは結構疲れました。ちなみにその週はずっと彼をアテンドしていたので、若干英語力が上がったかも。

インタビューの前にGraph APIを使ってWAADで使うSaaSアプリケーションの管理もできるようになるといいなぁ、という話をホワイトボードを使ってディスカッションしていたりしました。（見えないと思いますが）

だいぶ間は空いてしまいましたが、とり合えず１週間お疲れ様でした。


おまけ（＠東京から京都へ移動する前に東京駅で寿司をｗ）

[WAAD]セルフサービス・グループ管理と承認フロー

日々いろいろと機能がリリースされている（※）Windows Azure Active Directory（WAAD）ですが、今回は利用者自身によるグループ管理と承認フロー（いずれもPremium版のプレビュー機能）を試してみます。
※ちなみに本日も新しいレポート機能がリリースされてました。

■概要

アプリケーションパネル（http://myapps.microsoft.com）からグループの作成、グループへの参加申請、承認が出来るようになっています。

■利用シーン

同じくプレビュー機能でグループを組織が使うアプリケーション（GoogleAppsなどのSaaSアプリケーション）に割り当てることが出来るようになっているので、利用者自身がグループへ参加申請し、グループオーナーが承認することで管理者でなくてもアプリケーションを使わせることが出来るようになります。

こんな感じです。

■動作を試してみる

◇初期状態の確認

　一般ユーザにはSaaSアプリケーションが割り当てられていないのでまだアプリケーションは使えない状態です。アプリケーションパネルを開いても何も出てきません。

◇事前作業：グループの作成（グループオーナー／一般利用者の作業）

　アプリケーションパネルからグループを作成します。
　※ちなみに管理者（マイクロソフトアカウント）が管理ポータルから作成したグループだと参加申請がうまく行かないので、組織のアカウントを使ってグループを作成しておく必要があります。ここでは組織アカウント（管理権限のない一般利用者）でアプリケーションパネルへログインして、セルフサービスでグループを作成しています。

まずはアプリケーションパネルへアクセスし、グループメニューを開きます。（WAAD Premiumプレビューの有効化を事前にしておく必要があります）

[Create a Group]をクリックするとグループ作成画面になるので、グループ名を入れてグループを作成します。

[Create]をクリックするとグループが作成できます。


◇事前作業：アプリケーションへグループを割り当てる（管理者作業）

　管理ポータルでグループ一覧を開くと先ほど作成したグループが表示されているのがわかります。

　このグループをSaaSアプリケーションに割り当てます。

　これで準備は完了です。


①グループへの参加申請

　先ほどのグループオーナーとは別のユーザでアプリケーションパネルへアクセスし、グループメニューを開きます。今度はグループへの参加を申請します。
　少しわかりにくいのですが参加したいグループのアイコンの右下の歯車をクリックすると[Join]というメニューが出てくるのでクリックします。

　リクエストが成功するとグループオーナーへ承認依頼が行きます。

②グループ参加申請を承認する

　グループオーナー（先ほど事前作業でグループを作成したユーザ）でアプリケーションパネルへアクセスし、今度は承認メニューを開きます。
　すると、先ほどの申請が届いているので選択⇒承認を行います。

　これでグループへの参加が承認されるので先ほど申請したユーザはグループに割り当てられたSaaSアプリケーションが使えるようになっているはずです。


③アプリケーションを利用する

　改めてアプリケーションパネルを開きます。すると先ほどは何も出てこなかったアプリケーションメニューにグループに割り当てられたアプリケーションが表示されます。

　また、グループメニューから先ほど申請したグループのメンバになっていることもわかります。
　（ドロップダウンからMy Membershipを選択すると自身がメンバになっているグループが表示されます）

■まとめと今後の展開


　まだまだプレビュー機能ということもあり若干機能不足な感じはしますが、小規模な企業であればWAADのグループ機能を使ってうまくSaaSアプリケーション利用の承認フローが実装できると思います。

　もう少しちゃんと使おうと思うと、最低限以下の機能は必要だと思うので、今後に期待したいところです。

• すべてのグループが表示されてしまうので、ユーザの権限によってグループの表示や申請自体が出来ないようにフィルタイングする
• グループオーナー権限の委譲（複数人で承認出来るようにする）
• グループオーナーが削除されてしまうとグループへの参加が出来なくなる