[FIM2010] R2 向け Best Practices Analyzer がリリース

これは一度でも FIM をインストール・設定したことがある人なら理解できると思いますが、インストールや設定に際してかなり細かい設定項目や前提事項が存在しています。

真面目にやろうとすると、このような本を片手に頑張ることになるのですが、中々面倒くさいのも事実です。

FIM Best Practices Volume 1: Introduction, Architecture And Installation Of Forefront Identity Manager 2010

通常私達がセットアップをする場合は、そのあたりをまとめたスクリプトや設定テンプレートを使ってしまうのですが、結果を一括で確認できるという点では今回リリースされた様な Best Practices Analyzer はとても便利です。

ダウンロード URL

http://www.microsoft.com/en-us/download/details.aspx?id=30419

尚、このツールを使うには事前に MBCA2.0（Microsoft Baseline Configuration Analyzer）をインストールしておく必要があります。

ダウンロード URL

http://www.microsoft.com/en-us/download/details.aspx?id=16475

早速使ってみます。

まずは起動して Select Product より Forefront Identity Manager 2010 R2 BPA を選択して Start Scan をクリックします。

次の画面で分析対象のパラメータを設定します。今回の環境では CLM および BHOLD は使っていないのでチェックを入れていません。

Start Scan をクリックすると分析が開始され、しばらくすると結果が表示されます。

ここでは、FIMService / FIMSyncService のアカウントのバッチジョブとしてのログオン拒否のポリシーが有効化されていない点と SQL Server Agent のジョブが有効になっていない点がエラーおよび警告として表示されています。

結果をクリックすると詳細が表示され、対応方法について記載された Web サイトへのリンクも用意されています。

では、分析結果で指摘された事項を修正していきます。

まずはサービスアカウントがバッチジョブとしてログオンできない様にポリシーを構成します。

次に SQL Server Agent のジョブで一部有効化されていないものがあったので有効化しておきます。

構成したら再度、ツールで分析をしてみます。

すると今度は問題が表示されなくなります。

みなさんも設定が一通り完了したら一度このツールを使って正しく設定されているかを最後に確認してみることをお勧めします。

[WAAD]Graph API で Office365 アカウントを管理する

Windows Azure Active Directory（WAAD）は Office365 などで利用されるマイクロソフトのオンライン・ディレクトリ・サービスです。
ということは Office365 のユーザ情報は WAAD 内にストアされており、Graph API で管理することが出来る、ということになります。

早速、Office365 のユーザの情報を Graph API で取得してみたいと思います。

まず当然ですが Office365 上にユーザを作っておきます。

このユーザ情報を Graph API を試すためのツールである Graph Expolorer を使って取得してみます。

このツールの Resource の値に
  - https://directory.windows.net/sub02adfs.onmicrosoft.com/Users
という形で対象ドメインと取得リソースを指定すれば値が取得できるはずです。

早速、GET をクリックしてみると、、、当然認証が走ります。

この中の Principal Id とか Symmetric Key とは何を指しているのかが、よくわかりません。

このあたりのドキュメントを読むと Graph API を使うには Service Princial を作成するという作業が必要の様です。
 - How-to Procedure: Authenticate To Windows Azure AD Graph Using Windows Azure AD Access Control
   http://msdn.microsoft.com/en-us/library/hh974468

具体的には Office365 の Powershell コマンドレットを使って Service Principal Id を取得するスクリプトを実行する必要があります。
※事前に Microsoft Online Servies サインインアシスタントも必要


ただ、面倒なので既に用意されているスクリプトを使いましょう。
 - PowerShell authorization script
   http://iddemo.blob.core.windows.net/files/CreateServicePrincipal.ps1

上記は直リンクですが、CodePlex で公開されているサンプルアプリケーションの中にもスクリプトが含まれていますので、そちらを利用しても良いでしょう。

 - サンプルアプリケーション
   http://code.msdn.microsoft.com/Sample-App-for-accessing-d71122ff

この中の「C#\PowerShell Scripts」の中に、CreateServicePrincipal.ps1 が上記からダウンロードできるスクリプトと同じものです。


このスクリプトを実行すると Service PrincipalName の指定するように要求されるので、任意の名前を入力します。

Windows Azure Active Directory 内でのユニーク性のチェックが行われ、問題なければマイクロソフト・オンライン・サービスの認証が走り、4つの値が払い出されます。

・Company ID
・AppPrincipal ID
・App Principal Secret
・Audience URI

この値の中の、AppPrincipal ID が先ほどの Graph Explorer の Principal Id、App Principal Secret が Symmetric Key に対応しているので、先ほどのログイン画面でその値を入力しログオンするとユーザの情報が表示されます。
※他の値については SSO を行う際に使うものなのでそのうち紹介したいと思います。

さきほど Office365 上に作ったユーザも確認できます。

今回は単に一覧を表示するだけでしたが、当然追加・変更・削除も出来るので、今後は Office365 へのプロビジョニングを DirSync に頼らなくても出来る様になってくると思います。
TechEd North America のセッションを見ていると既に FIM 2010 用の Graph API Management Agent を開発している会社もあるようなので、より柔軟にオンライン・アカウントを管理出来る様になってくると思います。

Windows Azure Active Directory Developer Preview が公開

European Identity Conference の Keynote で Kim Cameron 氏が語った Microsoft の IDMaaS（Identity Management as a Service）の実現である Windows Azure Active Directory の Developer Preview がアナウンスされました。

 - Windows Azure Team blog
   Announcing the Developer Preview of Windows Azure Active Directory
   http://blogs.msdn.com/b/windowsazure/archive/2012/07/12/announcing-the-developer-preview-of-windows-azure-active-directory.aspx

 - Vibro.NET / Vittorio Bertocci
   Single Sign On with Windows Azure Active Directory: a Deep Dive
   http://blogs.msdn.com/b/vbertocci/archive/2012/07/12/single-sign-on-with-windows-azure-active-directory-a-deep-dive.aspx


あわせて、各種ドキュメントやサンプルツールなどもリリースされています。

 - MSDN ドキュメント
   http://msdn.microsoft.com/en-us/library/hh974476

 - サンプルアプリケーション
   http://code.msdn.microsoft.com/Sample-App-for-accessing-d71122ff

 - Graph Explorer / テスト用ツール
   https://graphexplorer.cloudapp.net


更に興味深いのが Kim Cameron 氏が 最新の blog エントリ「Yes to SCIM. Yes to Graph.」で語っている Graph API と SCIM（Simple Cloud Identity Management）の関係です。


エントリの中で Kim 氏は基本的に SCIM の目指しているゴールをサポートしており、マイクロソフトとして取り組みを支援する姿勢を見せています。

しかし、何故マイクロソフトは SCIM を採用せずに Graph API を検討しているのか？という疑問に対する解として以下の2点を挙げています。

１．多様なオブジェクトが相互に多様な関係性の中に存在する環境において Graph API は検索や操作性において統合されたアプローチを提供するため。

　つまり、SCIM で提供されているスコープ（現状はユーザとグループオブジェクト）以上のオブジェクトと複雑な関係性を表現する上では Graph API の方が向いている、ということでしょうか。

２．巨大なスケールにおいてディレクトリは「多次元ネットワークを表現するものに変化する」ため。

　今後のディレクトリ内にストアされるオブジェクトは全てにつながり、多くのディメンジョンを持つことになるため、 オブジェクトを扱うためには Graph API が必要だ、ということでしょうか。
　例として、レガシーなディレクトリは組織や人やグループなどのオブジェクトを持っていて、組織は人を含み、グループは階層化されている、という様な構造を持っていましたが、ソーシャル構造を表現する必要が出てきている、という話が挙げられており、レガシーな単一指向性のディレクトリでは構造を表現することが不可能になってきている、という主張なのだと思います。


Kim Cameron 氏は次の blog エントリでも Windows Azure Active Directory のリリースについて書く、と宣言しているのでしばらくは目が離せそうにありません。

[Office365/AD FS2.0] クライアント・アクセス・ポリシー・ビルダー

Office365 を AD FS2.0 と連携された環境で使う最大のメリットはオンプレミスの Active Directory とのシングルサインオンですが、他にも細かなアクセス制御を行うことが出来る、という重要なメリットがあります。
※AD FS2.0 Rollup 1 以降（Rollup 1 についてはこちら）


例えば、先月公開された Directory Services Team の blog では、

• 社内ネットワーク以外からは Outlook 経由でメールを見れなくする
• 特定のセキュリティグループに属するアカウントに ActiveSync を使わせない
• 特定のセキュリティグループに属するアカウントは社内ネットワーク以外から OWA を使わせない
• 全 OWA ユーザにフォーム認証を強制する

というシナリオに応じた AD FS2.0 の Claim ルール（要求規則）を記載しています。

また、簡単なアクセスポリシーを GUI で設定するためのツールである「クライアント・アクセス・ポリシー・ビルダー」が Technet の Script Center で公開されています。

　- Client Access Policy Builder
　　http://gallery.technet.microsoft.com/scriptcenter/Client-Access-Policy-30be8ae2


設定可能なアクセスポリシーは以下の通りです。

■アクセスポリシー

• 社外ネットワークから Office365 へアクセスさせない
• 社外ネットワークから Office365 へアクセスさせない（ActiveSync を除く）
• 社外ネットワークから Office365 へアクセスさせない（OWA や SharePoint Online の様なブラウザベースのアプリケーションを除く）
• 社外ネットワークから Office365 へアクセスさせない（特定のセキュリティグループのメンバとなっている場合）
• 社外ネットワークから Office365 へアクセスさせない（Outlook クライアントからのアクセスの場合）

■社外ネットワークの定義

• 単一のIPアドレス
• IPアドレスの範囲

使い方は非常に簡単で、上記 URL からダウンロードできる PowerShell スクリプトを AD FS2.0 サーバで実行すると GUI が起動するので、[Create Rules for Claim Types] をクリックすると AD FS2.0 上に Claim Rule を作成し、あとは使いたいポリシーの選択、社外ネットワークのアドレスを設定するだけです。

ポリシーを設定後、画面右下の[build]ボタンをクリックすると AD FS2.0 上に Claim Rule が作成されます。

尚、以下の様な注意点があります。

• 外部からダウンロードした PowerShell ファイルなので、Set-ExecutionPolicy -Unrestricted を実行して本ツールを起動出来る様にする（実行後は制限を元に戻すことをおすすめします）
• AD FS2.0 の管理コンソールが起動しているとツールが使えないので、管理コンソールは落とした状態で使う必要がある
• 念のため、本ツールを使う前に既存の Claim Rule はバックアップしておく方が好ましい

Claim 記述言語は結構ややこしいので、このような GUI ツールを使って設定するのが確実だと思います。
他の汎用ルールについてもこのような GUI ツールが出てくると良いですね。