2011年2月20日日曜日

クレームの発行状態を確認する

AD FS2.0やAppFabric ACSを使った外部認証を有効にしたアプリケーションを開発しているとちゃんとセキュリティトークンが発行されているのか、トークンの中のクレームに何が入っているのかの確認をしたくなります。
もちろんfiddlerを使って実際のHTTPのやり取りの中からPOSTされるSAMLトークンをキャプチャしてSAML 2.0 Debuggerでデコードする、というのもやり方としてはありなのですが、いかんせん生のXMLを見ていく必要がありますし何より手順として少々面倒です。

ということで、私が使っているのがSecurity Token Visualizer Control(STVC)です。PDC等のカンファレンスでVittorioさんが使っているのを見たことがある方もいらっしゃると思いますが、彼がcodeplexに公開しているSAML2.0のトークンを解析して表示してくれるコントロールです。

公開URL:
http://archive.msdn.microsoft.com/TokenVisualizerCtrl

最新版:
SecurityTokenVisualizerControl PDC09 WIF RTM


■環境の構築
※WIF SDKやVisual Studio、IISのアプリケーションプールの設定が正しくされている前提です。

・アーカイブを展開する
では、さっそく使ってみましょう。上記URLからダウンロードしたファイルを実行するとアーカイブの展開および環境のチェック、デプロイが行われるのですが最新版がPDC09とあるように少々古い環境なので最近の環境ではそのままでは使えず、セットアップ過程におけるDependency Checkerでこけてしまいます。これは前提となる環境がVisual Studio 2008だったりするせいなので、アーカイブの展開が終わったらさっさとキャンセルボタンを押してセットアップは省略してしまいましょう。
すると、展開先のフォルダ以下にアーカイブが展開され、「code\Microsoft.Samples.DPE.Identity.Controls\bin\Debug」以下にSecurityTokenVisualizerControl.dllが出来ています。
もちろん同梱されているプロジェクトをVisual Studio 2010でビルドしなおしてdllを再作成してもOKですが、面倒なのでこのdllをそのまま使ってしまいます。

・作成するプロジェクト内でSTVCを利用する
この辺りはVisual Studioを使い慣れている方には当たり前なのでしょうが、上記で解凍したコントロール(dll)をプロジェクトで使えるようにするためにコントロールを参照する必要があります。

ツールボックスを表示して、コントロールの参照から解凍したdllを参照します。
すると、ツールボックス内にSTVCのアイコンが出てきますので、プロジェクトのWebページ上にドラッグ&ドロップします。これでコントロールの配置は完了です。




















・Federation Utilityを実行しSTSへの参照設定を行う
ここはAD FS2.0やACSを使った外部認証を有効にする手順と同じですが、Federation Utilityを使ってSTS参照を有効にします。今回はACSを参照することにします。
※もちろんACS側へのRelying Partyの設定も必要です。














・ちょこっとweb.configを修正する
実はFederation Utilityを実行してもweb.configに手動で設定を行う必要があります。(.NET Framework 4.0を使う場合のみ?)結構はまりポイントなので、うまく動かない場合は一度このあたりの設定を疑ってみる必要があるかもしれません。

<system.web>以下
 <httpRuntime requestValidationMode ="2.0"/>

<microsoft.identityModel>以下
 <service saveBootstrapTokens="true">


これで準備は完了です。

■使ってみる
では、作成したプロジェクトを発行してWebページにアクセスしてみます。

まずはACSで認証されます。




















うまくトークンとクレームが発行されていれば、Webページのコントロールをクリックして展開されるテーブルにトークンの情報が表示されるはずです。













上の方に発行されたクレームの型と値、発行元の情報が、下の方に実際に発行されたSAMLトークンの情報が表示されているのがわかります。


アプリケーションのデバッグはもちろん、AD FS2.0やACSなどの基盤が正しく動作していることの確認を行うためにも使えそうです。(もちろんデモ用途にも)

2011年2月2日水曜日

[FIM2010]一般ユーザ権限でセキュリティグループを管理する

FIM2010の大きな特徴でもあるグループ管理機能も実はデフォルトでは殆ど無効化されているので色々と手を加えてやる必要があります。

以下が一般ユーザでFIMポータルにログインした際の初期画面です。











見ての通り、配布グループについては表示されていますが、セキュリティグループについては表示すらされていません。(実は配布グループについても画面表示はされていても実際に作成をしようとするとアクセスが拒否されてしまうので、そのままでは使えません)

この状態から一般ユーザが自身でセキュリティグループの管理ができる状態にするためには以下のステップを踏む必要があります。
・画面に操作メニューを表示する
・セキュリティグループを管理する権限を付与する

それぞれを解説していきます。

■画面に操作メニューを表示する
まず、画面のカスタマイズです。

FIMポータルの画面の中のユーザメニューに関連する部分は
・ナビゲーションバー
・ホームページ
で構成されています。












それぞれに何を表示するか、についてはAdministratorでログインした場合にポータルの右側に表示される管理メニューより対応するリソースのカスタマイズを行います。


















では、どうすればホームページやナビゲーションバーに各機能が表示されるか?ですが、これは少しわかりにくいのですが、各リソースの「使用法キーワード」に「BasicUI」という文字列を入れることで表示されます。

ナビゲーションバーリソース
















ホームページリソース

















ここまで設定をすると一般ユーザのポータルにもメニューが表示されます。(すぐに画面に反映させたい場合はiisreset等でIISを再起動してください)














次は表示されたメニューを実際に使えるようにします。

■セキュリティグループを管理する権限を付与する
先の配布グループの件もそうなのですが、一般ユーザがセキュリティグループを管理できないのは以下の2点が原因です。
・関連する管理ポリシー規則(MPR)がデフォルトでは無効化されている
・関連する管理ポリシー規則の申請元として定義(許可)されているのがAdministratorsのみである

それぞれを解消して行きます。

まず、管理ポリシー規則の有効化です。
対象となる管理ポリシー規則は「Security Group xxxx」という表示名のものです。検索ウィンドウに「Security」と入れて検索すると対象のもののみが表示できるので便利です。
それぞれの管理ポリシールールを開いて[無効化]のチェックを外して保存すればOKです。








次に、管理ポリシー規則を利用するための権限の付与です。
デフォルト状態を見てみるとセキュリティグループ管理を行うための管理ポリシー規則の申請元として定義されているのは「Security Group Users」というセットです。
このセットの定義をみるとメンバとなっているのはAdministratorsに属するユーザのみとなっているので、ここに一般ユーザも追加することで権限を与えることが可能です。


















さて、それなりに長い道のりでしたがここまで設定を行ってようやく一般ユーザでもセキュリティグループを管理することができるようになりました。
(もちろんFIMで作ったセキュリティグループをActive Directoryへ反映させるには別途管理エージェントの設定や同期規則の設定が必要です)

2011年1月25日火曜日

NSF2011

今日はJNSA主催のNSF2011(Network Security Forum 2011)でした。

私もJNSAのアイデンティティ管理ワーキンググループで活動している関係で「クラウド時代のアイデンティティ管理」というテーマで少々話をさせていただきました。



しかし、いつも思うのですがテーマとして漠然としている「クラウド」や「アイデンティティ管理」の両方がかけ合わさっているので余計に分かりづらく、なかなかリスナーに響くプレゼンができないのが悩みです。。。(プレゼン技術の問題も多々あるのですが)

主旨は、
・クラウド上のサービスを使うからと言って情報セキュリティマネジメントのポリシーが変化するわけではない
・ただし環境(ネットワーク境界など)は変化しているので、それ相応のリスク対策は必要である
・ENISAなどクラウドのリスクの洗い出し/評価をしている組織もあるのでまずはそれを参考に
・フェデレーションやクラウド上のリソースへのプロビジョニングなどリスクを低減するためのソリューションも出てきているのでうまく活用を
といったところです。

必要以上に「クラウド」を敬遠せずに有効に活用していければ、、と切に願います。

2011年1月23日日曜日

[FIM2010]有効かすべき管理ポリシー規則(MPR)のチェック

何度やってもインストールは難しい(真面目にパーミッションやトポロジを考えると)し、インストールしただけでは何にもできないFIM2010ですが、その中でももっとも判断に迷うポイントの一つが「どの管理ポリシー規則(MPR)を有効化すべきか?」だと思います。

そもそもデフォルト状態では一般ユーザではポータルアクセスもできないし、セキュリティグループへの参加もできない、という状態なのでプロジェクトを進める中で「誰に何を許可するか」を管理ポリシー規則として設定していくことになるのですが、ここでは最も一般的な操作をする際にまず有効化すべき規則の状態をチェックする方法を書いておきます。

・デフォルトではポータルにアクセスすらできない















チェック用スクリプト(PowerShell)
http://social.technet.microsoft.com/wiki/contents/articles/how-to-use-powershell-to-check-your-mpr-configuration-for-synchronization.aspx

このスクリプトは実行時に構成されているオブジェクトタイプ(ユーザのみなのか、グループも対象なのか)を判別し、その時点の管理ポリシー規則の状態と一般的に必要な状態の差分を洗い出して不足している設定を教えてくれます。

たとえば、ユーザの同期を行う様な構成をしただけの状態でスクリプトを実行すると、

FIM MPR Configuration For Synchronization Check
===============================================
MPRs that need to be enabled:
-General: Users can read non-administrative configuration resources
-User management: Users can read attributes of their own
-Synchronization: Synchronization account can read group resources it synchronizes
-Synchronization: Synchronization account controls group resources it synchronizes

という形で4つの管理ポリシー規則を有効化する必要があることを教えてくれます。

この情報をもとに管理者ポータルからポリシーを有効化します。
















修正後、再度実行すると

FIM MPR Configuration For Synchronization Check
===============================================
Your current MPR configuration meets all requirements

という形で修正は必要ない、と言われます。

この状態であればポータルへもアクセスできます。














管理対象やポリシーが変わった時は都度このスクリプトを実行して状態をチェックしてみるとよいかもしれません。

[FIM2010]管理エージェントの情報が管理者ポータルに出てこない

久しぶりにFIM2010ネタを。

FIM2010ではMIIS/ILMから引き続き管理エージェント(MA)を使った同期設定・実行を行うFIM Synchronization Serviceとポータル等のWebサービスを管理するFIM Serviceの2つのサービスが稼働しています。

同期対象のリソースを設定する際は、
1.Synchronization Service Managerで管理エージェントを作成する
  →同期対象のリソースへの接続設定等を行う
2.管理者ポータルで同期規則、ワークフロー、管理ポリシー規則を作成する
  →細かな同期条件や属性フロー設定等を行う
という流れになります。

当然1のSynchronization Service Manager(Synchronization Service側)で作った管理エージェントの設定情報が2の管理者ポータル(FIM Service側)に同期されていないと同期規則を正しく設定できません。

正しくシステムが動作している時は2つのサービスの間で管理エージェントの情報のレプリケーションが実行されているのですが、過去に2回ほどいくらSynchronization Service Managerで管理エージェントを作っても管理者ポータルから見えない、という状態になったことがあります。

その状態になった時はイベントログに以下の様な情報が記録されます。

****************************************
管理エージェントまたはメタバースの構成の更新内容を、ターゲットのコネクターディレクトリにレプリケートできませんでした。その結果、このコネクターディレクトリーの管理エージェントまたはメタバース構成は最新の状態ではありません。 エラーの原因である状態を解決して、ターゲット管理エージェントのパスワード情報を更新するこ とで、再同期が行われるようにしてください。

追加情報:
エラー コード: 0x80230709
エラー メッセージ: (The extension operation aborted due to an internal error in FIM Synchronization Service.)
操作: Update MA
レプリケート対象の管理エージェントの名前: AD MA
レプリケート対象の MA の GUID: {C7DB5C1A-8D98-4F1A-8AFE-8C2E198DADEF}
ターゲットの MA の名前: FIM MA
ターゲットの管理エージェントの GUID: {8676CD7A-9ADA-455C-9363-714FAE21CC6D}
****************************************

原因は2つのサービスの間で情報のレプリケーションがうまくいっていないことなのですが、どうやって解消するのか調べているとこんなページが出てきました。

http://idamd.blogspot.com/2010/06/ma-attributes-not-listed-in-fim-sync.html


どうもうまくいっていないようです。再インストールしかないのか?と思いもう少し調べていると以下のKBにたどり着きました。

Update Package 1 for Microsoft Forefront Identity Manager (FIM) 2010
http://support.microsoft.com/kb/978864

要するにFIM ServiceとFIM Synchronization Serviceのパッチのバージョンを合わせる必要があるとのこと。

いわれてみれば当たり前なのですが、はまりポイントはMicrosoft Updateを使う場合、
・FIM Serviceのパッチは重要な更新
・FIM Synchronization Serviceのパッチはオプション更新
である点です。

つまり、Synchronization Service側のパッチは明示的に選択しないとインストールされないので両者の更新状況にズレが発生してしまいます。

運用するうえでは気を付けないといけませんね。

ちなみにSynchronization Service側も更新したら正常にレプリケーションが開始され、ちゃんと管理エージェント情報が管理者ポータルからも参照できるようになりました。

2011年1月11日火曜日

Office365とAD FS2.0の認証連携

ベータプログラムが公開されてからしばらく時間が経ちましたが、順番待ちでなかなか使えるようにならないので悶々と情報をあさる日々が続きますが、そんな中でも少しずつ情報が出始めているようです。(MVP for Office365っていうのも出てきたようですし)

その中で興味深いblogエントリがあったので紹介します。(Avanadeのオランダの方が書いているもののようです)

360 on 365

#Office365 and #ADFS2.0, how does it work?
http://360on365.com/2010/12/31/office365-and-adfs2-0-how-does-it-work/


最近ちょこちょこ情報として出始めている中で騒がれている制限事項(前提事項)がやはり一番に紹介されています。
・オンプレミスのActive DirectoryのUPN属性がインターネットから解決出来る必要がある
 →下手に.localドメインで社内ADを構築しているとかなり大幅な変更になるかも知れません。他のアプリケーションへの影響もあるでしょうし。。FIM2010などの自動化ツールは必須かも知れません。
・Office365からのドメインの正当性確認を受ける必要がある
 →LiveIDとのFederationの時にもはまりましたが、Office365というかMFG(Microsoft Federation Gateway)が認めてくれる必要があります。証明書の発行元はシビアです。。


ベストプラクティスとしては、以下の手順が推奨されています。
・初めにDirecrtory Synchronizationをセットアップし、オンプレミスユーザをクラウドに同期する
・次にフェデレーション信頼を確立する

フェデレーション信頼の確立を行ううえでは、Microsoft Online Services Identity Federation Management Toolが用意されていて、PowerShellのコマンドレットを使ってオンプレミスとOffice365のフェデレーションを設定することができる様です。以下、コマンドレットの例。
 Set-MSOLContextCredential
 Add-MSOLFederatedDomain
 Convert-MSOLDomainToConverFederated
 Get-MSOLFederationPropert
LiveIDの時に使ったFederationユーティリティと同じようなお手軽設定ツールですね。

基本的にLiveIDと同じくMicrosoft Federation Gatewayを使う構成になるため、ユーザのアクセスフローは以下の通りです。
1.Office365ポータルへアクセス
2.IDを入力(xxx@xxx.xxx)形式
3.Microsoft Federation Gatewayドメイン名よりレルムを判断してIdP(オンプレミスのAD FS2.0)へリダイレクト
4.AD FS2.0で認証
5.発行されたセキュリティ・トークンをMicrosoft Federation Gatewayへポスト
6.Microsoft Federation GatewayがOffice365用に変換したセキュリティ・トークンをポスト
7.ユーザがログイン


何しろ早く触ってみたいです。

2011年1月7日金曜日

[AD FS]RTWのパッケージが更新されてます

2011/1/5に地味にアップデートされてます。
http://www.microsoft.com/downloads/details.aspx?FamilyID=118c3588-9070-426a-b655-6cec0a92c10b&displayLang=ja

以下のKBに対応したということらしいです。
http://support.microsoft.com/kb/2254265
 The "500" error code is returned when you send an HTTP SOAP request to the "/adfs/services/trust/mex" endpoint on a computer that is running Windows Server 2008 R2 or Windows Server 2008
http://support.microsoft.com/kb/2272757
 An identity-provider-initiated sign-on process is slow in Windows Server 2008 R2 and in Windows Server 2008