2010年5月26日水曜日

クレイムベースのアイデンティティ&アクセスコントール本が届きました

先日「早わかり!クレイムベースのアイデンティティ&アクセス管理」というポストで紹介したA Guide to Claims-Based Identity and Access Controlですが、内容的に非常に興味深かったので、著者のEugenio Pace氏に連絡をしてみました。
中々興味深い分野なので今後も継続的にやり取りができると良いなぁ、、と思っています。

やり取りの中で先の文書のハードコピーを頂いたので(しかもサイン入り!)紹介します。

ハードコピー











サイン!












彼のblogエントリには他にもAzure関連のガイダンスなど参考になるものが多くあるので、今後も要ウォッチです。

ついでに、昨日のInfoQにEugenio氏へのADFS2.0とWIFに関するインタビューが載っていましたのでこちらも紹介。



2010年5月24日月曜日

ツアー終了

先週から始まったエクスジェン・ネットワークス東名阪ツアーが本日終了しました。

様々な方々に来て頂き、「ブログ見てます!」というお言葉を頂き、非常に勇気づけられた1週間でした。皆さまにはとても感謝しております。

内容ですが、メインテーマは「IdM製品の傾向」でしたが、アイデンティティ管理自体に関するトレンドの推移やアイデンティティ情報の管理および利用モデルの移り変わりについて簡単ではありますが紹介させていただきました。

簡単に概要ですが、アイデンティティ管理を行う目的として、
  • 運用の効率化
  • セキュリティの強化
  • 利便性の向上
  • 法令対応/内部統制
といったキーワードが絡み合ってプロジェクトが複雑化しがちですが、それらのキーワードがここ10年程度を振り返ってどのような経緯で持ち上がってきたか、各製品ベンダはどのような機能でそれらのキーワードに追従してきたか、を紹介しました。
















また、クラウド(主にSaaS)をイメージした際に、アイデンティティ情報を提供する側、サービスを提供する側それぞれの間を結ぶのは「信頼」であること、USガバメント(ICAM、OIX)やIAFの例をベースに保証のフレームワークを簡単に紹介しました。
















全体に少々企業内のプロビジョニングとは離れた世界の話になりましたが、今後考えなければいけない事柄ばかりだと思うので、非常にざっくりですが紹介出来て良かったと思います。

いづれにしても、上記のような複雑な要件が絡み合うが故にややこしいプロジェクトになってしまいがちなアイデンティティ管理ですが、今後もしばらくはややこしさが付いて回りそうです。。。。

2010年5月17日月曜日

[FIM]勝手に翻訳:Active Directory Domain Servicesへのユーザプロビジョニング その2

以前の続きで、今回もTechnetフォーラムの記事を勝手に翻訳していきます。

前回はFIM Synchronization Serviceの設定を行ったところまでやりましたので、今回はFIM Serviceの設定から始めます。

FIM Serviceを構成する
本ガイドのシナリオではプロビジョニングポリシーを構成する必要があります。

















このプロビジョニングポリシーの目的は契約社員をADユーザの発信同期規則のスコープに入れることです。
リソースを同期規則のスコープに入れると設定に従い同期エンジンはAD DSにリソースをプロビジョニングします。

FIM Serviceを構成するには、Internet Exploreでhttp://localhost/identitymanagementに移動します。
プロビジョニングポリシーを作成するためには、FIMポータルページの[管理]セクションから関連するページへ移動します。
構成を確認するには、同期構成を出力するPowerShellスクリプトを実行します。

同期ルールを作成する
次の表はFabrikamプロビジョニング同期ルールに必要な構成を示しています。

同期規則の構成
表示名AD User Outbound Synchronization Rule
説明
優先順位1
データフローの方向送信
依存関係
スコープ
メタバースリソースの種類person
外部システムFabrikam ADMA
外部システムリソースの種類user
リレーションシップ
外部システム内にリソースを作成するTrue
デプロビジョニングを有効にするFalse
リレーションシップ条件
MetaverseObject:person(属性)ConnectedSystemObject:user(属性)
accountNamaesAMAccountName
初回の送信属性フロー
NULLを許可宛先ソース
Falsedn+("CN=",displayName,",OU=FIMObjects,DC=fabrikam,DC=com")
FalseuserAccountControl数値: 512
FalseunicodePwd文字列: Pa$$W0rd
永続的な送信属性フロー
NULLを許可宛先ソース
FalsesAMAccountNameaccountName
FalsedisplayNamedisplayName
FalsegivenNamefirstName
FalsesnlastName


ステップ6
上記の表のとおりに同期規則を作成します
重要)dnをターゲットとした属性フローは初回のみを選択したことを確認してください


ワークフローを作成する
AD プロビジョニング ワークフローの目的は、Fabrikamのプロビジョニング同期規則にリソースを追加することです。
次の表は、構成を示しています。

ワークフロー構成
表示名AD User Provisioning Workflow
説明
ワークフロータイプAction
ポリシー更新時に実行False
同期規則
名前AD User Outbound Synchronization Rule
動作追加


ステップ7
上記の表のとおりにワークフローを作成します


管理ポリシールールを作成する
必要な管理ポリシールール(MPR)はSet Transisionタイプであり、リソースがすべての契約社員というセットのメンバとなったことを契機に動作します
次の表は、構成を示しています。

管理ポリシー規則構成
表示名AD User Provisioning Management Policy Rule
説明
セット移行
権限の付与False
無効化False
移行の定義
移行の種類セットへの移行
移行セットAll Contractors
ポリシーワークフロー
タイプ表示名
ActionAD User Provisioning Workflow


ステップ8
上記の表のとおりに管理ポリシールールを作成します


環境を初期化する
初期化フェーズの目的は
・同期規則をメタバースに格納する
・Active Directoryの構成をActive Directoryコネクタスペースに格納する
ことです。
次の表は初期化フェーズの実行プロファイルを示します。

順序管理エージェント実行プロファイル
1Fabrikam FIMMAフルインポート
2
3エクスポート
4差分インポート
5Fabrikam ADMAフルインポート
6


ステップ9
上記の表のとおりに実行プロファイルを実行します
注)発信同期規則が正常にメタバースに投影されていることを確認してください。


構成をテストする
このセクションの目的は、実際の構成をテストすることです。 構成をテストするには、
・サンプルユーザをFIMポータルで作成
・サンプルユーザのプロビジョニング要件を確認
・サンプルユーザをAD DSへプロビジョニング
・ユーザがAD DSに存在することを確認
を行います。

・サンプルユーザをFIMポータルで作成
次の表は、サンプルのユーザのプロパティの一覧です。

属性
Britta
名前 (姓)Simon
表示名
AccountNameBSimon
ドメインFabrikam
契約者


ステップ10
上記の表のとおりにサンプルユーザを作成します


サンプルユーザのプロビジョニング要件を確認
サンプルユーザをAD DSへプロビジョニングするには、2つの前提条件が満たされている必要があります。
1.All ContractorsのSETのメンバであること
2.発信同期規則のスコープ内であること

ユーザがAll Contractorsのメンバかどうかを確認するには、SETを開き[メンバを表示]をクリックします。








ステップ11
ユーザがAll Contractorsのメンバであることを確認します。


ユーザが同期規則のスコープ内にあるかどうかを確認するには、ユーザのプロパティページを開き、プロビジョニングタブ内にあるExpected Rules List属性を見ます。
Expected Rules List属性の値ははAD User Outbound Synchronization Ruleになっているはずです。

次の図で確認方法の例を示します。









この時点では同期規則のステータスはペンディングです。
つまり、同期規則はまだユーザに適用されていません。

ステップ12
ユーザがADユーザ発信同期規則のスコープ内であることを確認します。


サンプルのユーザの同期
テストオブジェクトの初回の同期サイクルを開始する前に、テスト計画の中で各実行プロファイルを実行後のあるべき姿をトラッキングしておく必要があります。
テスト計画はオブジェクトのあるべき次の状態(作成、更新、削除)と属性値を含んでいるべきです。
テスト計画を使用して、期待されるテスト結果を確認します。
もしステップが期待通りの結果を返さない場合は、あるべき結果と実際の結果の不一致を解決するまでは次のステップへ進まないでください。

期待通りに動いているかを確認するには、最初の指標として同期の統計情報を利用することができます。
例えば、新しいオブジェクトがコネクタスペースにステージングされることを期待していたのに、インポートの統計の中の[Add]が0件だった場合、明らかに何か期待通りに動いていないものがあるということになります。












同期の統計情報でシナリオが期待どおりに機能しているかについての初期情報を確認することができますが、Synchronization Service Managerのコネクタスペースの検索とメタバースの検索機能を使って属性の値が予測された通りになっているかどうかを確認してください。

AD DSユーザを同期するには、以下の手順を実行します。
1.ユーザをFIM MAコネクタスペースにインポートします。
2.ユーザをメタバースへ投影します。
3.ユーザをActive Directoryコネクタスペースへプロビジョニングします。
4.FIMにステータス情報をエクスポートします。
5.ユーザをAD DSにエクスポートします。
6.ユーザの作成状況を確認します。

これらのタスクを完遂するためには、次の実行プロファイルを実行します。

管理エージェント実行プロファイル
Fabrikam FIMMA1.デルタ インポート
2.デルタ同期
3.エクスポート
4.デルタ インポート
Fabrikam ADMA1.エクスポート
2.デルタ インポート


FIMサービスのデータベースからのインポート後、Britta Simonと、BrittaをAD User Outbound Synchronization RuleにリンクするExpectedRulesEntryオブジェクトがFabrikam FIMMAのコネクタスペースにステージングされます。
コネクタスペースのBrittaのプロパティをみると、FIMポータルで設定した属性値とともにEREオブジェクトへの参照が設定されているのがわかります。

次のスクリーンショットがこの例です。















Fabrikam FIMMAでのデルタ同期の目的は、下記のいくつかの操作を実行することです。

・投影 - 新しいユーザオブジェクトおよび関連するExpected Rule Entryオブジェクトをメタバースに投影
・プロビジョニング - 新しく投影されたBiritta SimonのオブジェクトをFabrikam ADMDのコネクタスペースにプロビジョニング
・属性フローのエクスポート - 両方の管理エージェントで発生する属性フローをエクスポート。Fabrikam ADMAでは新しくプロビジョニングされたBritta Simonオブジェクトは新しい属性値で設定され、Fabrikam FIMMAでは既存のBritta Simmonオブジェクトおよび関連付けられたExpectedRuleEntryオブジェクトは投影結果により属性値が更新されます。

















既に同期統計情報により示されたように、プロビジョニングのアクティビティはFabrikam ADMAのコネクタスペースで行われます。
メタバースの中のBritta Simonのプロパティをみると、それらのアクティビティがExpectedRulesList属性値に正しく参照が割り当てらていることによりわかります。











続くFabrikam FIMMAでのエクスポートにおいて、Britta Simonの同期規則の状態はペンディングから適用へ更新されます。それは発信同期規則がメタバース中のオブジェクトに対してアクティブになったことを示しています。








新しいオブジェクトがADMAコネクタスペースにプロビジョニングされたため、この管理エージェントではペンディングエクスポートが追加されます。
Windows PowerShellを使って管理エージェントのエクスポート状態を表示する」というスクリプトを使うことによりFabrikam ADMAへ追加されるペンディングエクスポートを表示することができます。







FIMでは、エクスポート操作を完了するには、各エクスポートの実行毎に次のデルタインポートの実行の必要があります。
エクスポートの後に実行されるデルタインポートは確認のためのインポートと呼ばれます。
確認のためのインポートはFIM Synchronizationサービスが同期を成功させるために必要な適切な更新を行うために必要です。

ステップ13
上記の表のとおりに実行プロファイルを実行します。
注)各実行プロファイルがエラー無く完了する必要があります。


AD DSにユーザがプロビジョニングされていることを確認する
サンプルユーザがAD DSにプロビジョニングされていることを確認するには、FIMObjects OUを開きます。
Britta Simonが存在するはずです。





ステップ14
サンプルユーザがFIMObjects OUに存在することを確認します。


まとめ
このドキュメントの目的は、AD DSとFIMのユーザを同期するためのメインのビルドブロックに紹介することです。
初期のテストでは、タスクを完了するのに必要な最小数の属性で開始し、一般的な手順が正常に機能したら複数の属性をシナリオに追加してください。
複雑さを最小限に維持することがトラブルシューティングプロセスを簡素化します。

構成をテストする際、新しいテストオブジェクトを削除して再作成することがしばしば発生します。
ExpectedRulesList属性が設定されたオブジェクトにとってこれらの操作はExpectedRuleEntryの孤立を発生させます。
「孤立したExpectedRuleEntryオブジェクトを削除する方法」という記事はそれらのオブジェクトをテスト環境から削除する方法を説明しています。

同期先としてAD DSを含む典型的なシナリオにおいて、FIMはオブジェクトのすべての属性について権威を持っていません。例えば、AD DS内のユーザオブジェクトをFIMを使って管理する際、最低でもドメインとobjectSID属性はAD DS管理エージェントによって作成されます。アカウント名、ドメイン、ibjectSID属性はFIMポータルへログインを有効にする際に必要となります。AD DSからそれらの属性を設定するには、AD DSコネクタスペースに追加の着信同期規則を設定する必要があります。また、属性値に複数のソースを持つオブジェクトを管理するためには、属性フローの優先順位を正しく構成する必要があります。もし属性フローの優先順位が正しく構成されていない場合、同期エンジンが設定されたソースからの属性値をブロックしてしまいます。属性フローの優先順位の詳細については属性フローの優先順位についての記事を参照してください。

読むことを推奨する文書
設計コンセプト:FIMを使ってActive Directoryのアカウントを有効化もしくは無効化する
設計コンセプト:参照属性について
FIM MAアカウントをどのように管理すればよいですか?
権威のないアカウントを発見する - パート1:予測
設計コンセプト:コネクタ検出のメカニズム
設計コンセプト:ADMAアカウントを設定する
孤立したExpectedRuleEntryオブジェクトを削除する方法
属性フローの優先順位について
エクスポートについて

2010年5月16日日曜日

イベントで少々登壇します

クローズドなイベントですが、明日から東名阪ツアーです(笑)

国産IdM製品ベンダであるExgen Networksのパートナー向けイベントでID管理の動向、各種製品のすみ分けなどについて話をする予定です。

前段では運用効率化、セキュリティ、法令対応・統制、利便性など様々な目的が混じり合う中、アクセス管理を含むIdM製品群がどのような技術要素で対応・進化してきたのか、という大枠の話と、クラウドを含むサービス連携(Claimベースの話などを含む)がフォーカスされる中でプロビジョニングの役割はどうなっていくのか、について話をするつもりです。

後半は具体的な製品がそれぞれどのような特徴を持っているのか、という話をします。こちらは少々角が立つ話になるかも・・・

全部終わってひと段落したら公開出来そうなネタについては公開していこうと思います。

2010年5月6日木曜日

Active Directory Federation Services 2.0のRTWリリース

Ping Identityのblogで4月の終わりにリークされていましたが、AD FS2.0RTWが5月5日にリリースされました。
これで、Identity Metasystemを構成する3つの要素のうち、2つまでが正式にリリースされたことになります。
・Windows Identity Foundation [リリース済み]
・Active Directory Federation Services 2.0 [リリース済み]
・Windows Card Space 2.0 [ちょっと延期中]

Windows Card Space 2.0についてはU-ProveやOpenID対応の関連でちょっと延期されて、2010年Q2にCTPが出てくるようです。


さて、今回のRTW版ですがこれまでのユーザインターフェイスが英語のみだったのがインストーラ、管理コンソールやヘルプも日本語化されています。
ただ、相変わらずWindows Server 2008 without Hyper-Vにはインストール出来ないようです。特にHyper-Vを使うわけではないので、単にバージョンチェックではねているだけだと思いますが・・・

インストーラの画面。日本語になってます。
















管理コンソール。











構成ウィザード。















2010年4月19日月曜日

[FIM]勝手に翻訳:Active Directory Domain Servicesへのユーザプロビジョニング

Technetフォーラムの中には色々と役に立つコンテンツがあるのですが、その中の一つのFIM Expert Cornerを「勝手に翻訳」シリーズとして翻訳(意訳)して紹介していこうと思います。

今回はとりあえずベータ版の頃にこのblogでも紹介したAD DSへのユーザプロビジョニングの方法で、元ネタはフォーラムモデレータのMarkus Vilcinskasさんがポストしたこの記事です。ご本人に翻訳に関する確認をしたところ、快くOKしてくださったので紹介します。

というわけで早速。

■Actice Directoryドメインサービスへユーザをプロビジョニングするにはどうすればよいですか?

ID管理システムの1つの基本的な要件は、外部システムにリソースをプロビジョニングする機能です。
このガイドではForefront Identity Manager(FIM) 2010からActive Directory Domain Services(AD DS)へのユーザプロビジョニングのプロセスの主要な部分を紹介し、読者のシナリオが期待通りに動くかどうかの確認方法、FIMを使用してActive Directoryのユーザを管理するための提案、そして追加の情報ソースのリストを提示します。

・始める前に
このセクションでは、この文書のスコープについて定義します。
一般に、”How Do I"シリーズのガイドは関連するスタートガイドに記載されているFIMでオブジェクトを同期するプロセスに関する基本的な経験を持っている読者をターゲットにしています。

・想定している読者
このガイドは、既にFIMの同期処理のしくみに基本的な理解があり、この特定のシナリオに関するハンズオンや概念的な情報に興味のあるITプロフェッショナル向けに書かれています。

・前提となる知識
このドキュメントは、読者がFIM2010の実行環境へアクセスが可能で、以下のような簡単な同期シナリオを構築した経験があることを想定しています。
・着信同期の入門
・発信同期の入門
このドキュメント内のコンテンツは、これらの入門を拡張することを範囲としています。

・スコープ
このドキュメントで説明するシナリオは、基本的なラボ環境に対応して簡素化されており、コンセプトとテクノロジに理解を与えることにフォーカスされています。
このドキュメントは、読者がFIMを使用してAD DS内のユーザの管理するソリューションを開発することを支援します。

・必要な時間
この文書の中の手順を完了するには90~120分が必要です。
テスト環境の設定は既に完了しているものとし、テスト環境を設定するのに必要な時間は含まれません。

・サポートが必要な場合
このドキュメントの内容に関する質問があったりフィードバックがある場合や議論したい場合は、FIM TechNetフォーラムに気軽に投稿してください。
※訳注)英語です。

・シナリオの説明
架空の会社であるFabrikamは、FIMを使用して企業のAD DSのユーザアカウントを管理することを計画しています。
このプロセスの一環として、FabrikamはAD DSにユーザをプロビジョニングする必要があります。
最初のテストを開始するためにFabrikamはFIMとAD DSで構成される基本的なラボ環境をインストールしました。
このラボ環境上で、FabrikamはFIMポータル上で手動で作成したユーザを用いてシナリオをテストします。
このシナリオの目的は、あらかじめパスワードが定義された有効なユーザをAD DS上へプロビジョニングすることです。

・シナリオの設計
このガイドを使用するには、3つのコンポーネントが必要です。
1. Active Directoryドメインコントローラ
2. FIM Synchronizationサーバ
3. FIM Portalサーバ

次の図は、必要な環境の概要を示します。












すべてのサーバを1台のサーバ上で実行することが可能です。
 注)
 FIMのセットアップに関する情報はFIMインストレーションガイドを参照してください。

・シナリオコンポーネントの一覧
このガイドのシナリオで使用するコンポーネントは下表のとおりです。

組織単位FIM Objectsユーザをプロビジョニングする先として使用する組織単位
ユーザアカウントADMAAD DSに接続するのに必要な権限を持つActive Directory上のユーザアカウント
FIMMAFIMに接続するのに必要な権限を持つActive Directory上のユーザアカウント
管理エージェントと実行プロファイルFabrikam ADMAAD DSとデータ交換を行うための管理エージェント
Fabrikam FIMMA FIMとデータ交換を行うための管理エージェント
同期ルールAD User Outbound Synchronization Rule AD DSにユーザをプロビジョニングするための同期ルール
セットAll Contractors従業員タイプ属性の値が契約社員であるすべてのオブジェクトのための動的メンバシップを持つセット
ワークフローAD Provisioning WorkflowFIMユーザをAD発信同期規則に適合するために使用するワークフロー
管理ポリシーAD Provisioning Management Policy Rule リソースがAll Contractorsセットのメンバになった時に起動される管理ポリシー
FIMユーザBritta SimonAD DSにプロビジョニングするユーザ


・シナリオのステップ
本ガイドのシナリオは以下のブロックで構成されます。





















・外部システムの設定
このセクションでは、FIMの外部に作成する必要のあるリソースに関する手順を示します。

・組織単位を作成する
プロビジョニングされるサンプルユーザのコンテナとして組織単位が必要です。

ステップ1
AD DS上にFIMObjectsという名前の組織単位を作成します
注)組織単位を作成するための情報については組織単位を作成するを参照してください


・Active Directoryのユーザアカウントを作成する
本ガイドのシナリオのために2つのActive Directoryユーザアカウントを作成する必要があります。
・Adma - Active Directory管理エージェントのためのユーザアカウント
・Fimma - FIMサービス管理エージェントのためのユーザアカウント
両方とも通常のユーザアカウントを作成すれば問題ありません。
各アカウントの固有の要件はこのドキュメントで後述します。

ステップ2
先の説明に基づき、2つのActive Directoryユーザアカウントを作成します
注)ユーザアカウントを作成するための情報についてはユーザアカウントを作成するを参照してください


・FIM Synchronizationサービスの設定
このセクションの設定を行うためにはFIM Synchronizationサービスマネージャを起動する必要があります。

・管理エージェントを作成する
本ガイドのシナリオのために2つの管理エージェントを作成する必要があります。
・Fabrikam ADMA - AD DSのための管理エージェント
・Fabrikam FIMMA - FIMサービスのための管理エージェント

・Fabrikam ADMAを設定する

AD DS用の管理エージェントを設定する際、管理エージェントがAD DSとデータ交換を行う際に利用されるアカウントを決定する必要があります。
一般ユーザを使うべきですが、AD DSからデータをインポートするために、DirSyncコントロールに対して変更を検出する権限を持っている必要があります。
また、AD DSに対してデータのエクスポートするためにはターゲットOUに対して十分な権限を持っている必要があります。
この点に関する詳細情報はADMAアカウントを設定するを参照してください。

AD DSにユーザを作成するにあたり、技術的には対象のオブジェクトのDN属性さえ流し込めれば問題ありませんが、オブジェクトの検出をしやすくするためには、加えて姓、名、表示名を出力する方が良いと言えます。

AD DSではディレクトリサービスにログオンするのにsAMAccountName属性を使うのが一般的です。もしこの属性の値を指定しなかった場合、ディレクトリサービスがランダムな値を生成しますが、それら生成された値はユーザフレンドリではありませんので、AD DSへのエクスポートを行う際の典型的なシナリオではこの属性のユーザフレンドリな値を設定します。

ユーザがAD DSへログオン出来るようにするためには、同じくエクスポートロジックの中でunicodePwd属性にパスワードを設定する必要があります。

unicodePwd属性に設定する値がターゲットのAD DSのパスワードポリシーに合致していることを確認する必要があります。


AD DSのアカウントのパスワードを設定する際、同様にアカウントを有効化する必要があります。それを実現するためにuserAccountContorol属性を使用します。

userAccountControl属性に関する詳細はActive Directoryのアカウントを有効化/無効化するためにFIMを利用するを参照してください。


下表に必要となるシナリオ固有の設定を示します。

管理エージェント設定ページ設定
Create Management AgentManagement agent for: Active Directory Domain Service
Name: Fabrikam ADMA
Connect to Active Directory ForestSelect directory partitions: “DC=Fabrikam,DC=com”
Containersをクリックし、Select Containersダイアログを表示し、FIMObjects OUのみが選択されていることを確認する
Select Object Types既に選択されているObject typesに加えてuserを選択する
Select AttributesShow Allをクリックする
以下の属性を選択する
  displayName
  givenName
  sn
  sAMAccountName
  unicodePwd
  userAccountControl


ステップ3
前述の説明に従い管理エージェントを作成する
注)詳しくはヘルプの中の以下のトピックスを参照してください
  ・管理エージェントを作成する
  ・Active Directoryフォレストに接続する
  ・Active Directory管理エージェントを使用する
  ・ディレクトリパーティションを設定する
重要)ExpectedRulesList属性に設定するための着信同期規則が存在している必要があります



・Fabrikam FIMMAを設定する

FIM Service用の管理エージェントを設定する際、管理エージェントがFIM Serviceとデータ交換行う際に利用されるアカウントを決定する必要があります。
一般ユーザを使うべきですが、FIMをインストールする際に利用したアカウントと同一のアカウントである必要があります。
Windows PowerShellを使用したFIM管理エージェントのアカウント設定のクイックテストにはFIMのセットアップ時に使用したアカウントの検出と確認を行うためのスクリプトが含まれています。

下表はシナリオ固有の設定を行う上で最も重要な点を示します。


管理エージェント設定ページ設定
Create Management AgentManagement agent for: FIM Service Management Agent
Name: Fabrikam FIMMA
Connect to Database以下の設定を行う・Server:localhost・Database:FIMService・FIM Service base address:http://localhost:5725管理エージェント用に作成したアカウントを設定する
Select Object Types既に選択されているObject typesに加えてPersonを選択する
Configure Object Type Mappings既に選択されているObject type mappingに加えてData Source Object TypesPersonMetaverse Object Typespersonをマッピングする
Configure Attribute Flow既に存在する属性フローに加えて以下の属性フローを設定する
Object Type: Person
Object Type: person
Account NameaccountNameDirect
DisplayNamedisplayNameDirect
ExpectedRulesListexpectedRulesListDirect
FirstNamefirstNameDirect
LastNamelastNameDirect


ステップ4
前述の説明に従い管理エージェントを作成する
注)詳しくはヘルプの中の以下のトピックスを参照してください
  ・管理エージェントを作成する
  ・Active Directoryフォレストに接続する
  ・Active Directory管理エージェントを使用する
  ・ディレクトリパーティションを設定する
重要)ExpectedRulesList属性に設定するための着信同期規則が存在している必要があります

※訳注)ステップ3と内容が同じなのは原文のコピー&ペーストによるミスだと思われます。


・実行プロファイルを作成する

本ガイド内のシナリオのために必要な実行プロファイルは下記の通りです。

管理エージェント実行プロファイル
Fabrikam ADMA1.Full Import
2.Full Synchronization
3.Delta Import
4.Delta Synchronization
5.Export
Fabrikam FIMMA1.Full Import
2.Full Synchronization
3.Delta Import
4.Delta Synchronization
5.Export


ステップ4
前述の説明に従い各管理エージェントの実行プロファイルを作成する
注)詳しくはFIMヘルプの中の管理エージェント実行プロファイルを作成する、を参照してください
重要)provisioning設定が有効になっていることを確認してください。スクリプトを使って確認するにはWindows PowerShellを使ってprovisioningを有効にするを参照してください。





とりあえず前半部分でした。
次回は続きを載せたいと思います。

2010年4月8日木曜日

早わかり!クレイムベースのアイデンティティ&アクセス管理

先日マイクロソフトのPatterns&PracticesチームからリリースされたA Guide to Claims-based Identity and Access Controlを読み進めているのですが、ある意味シンプルなんだけどある意味とっつきにくい「クレームベースのアイデンティティ&アクセス管理」をとてもわかりやすく説明した例があったので紹介します。

以前Tech Fieldersコラムにフェデレーションの話を書いた時は入国審査を例にクレームベースのセキュリティについて説明しましたが、この今回紹介する例の方がより正確でシンプルで良いと思いました。

舞台は同じく空港なのですが、以下のようなメタファを用いています。

用語メタファ
セキュリティトークン搭乗券
クレーム名前、便名、座席ランク
STS(セキュリティトークンサービス)チケットカウンター
RP(アプリケーション)搭乗カウンター


これらを使って見事に認証、トークンの発行、トークンの確認とクレームによる認可を表現しています。















(1)利用者がチケットカウンター(STS)で認証される
   →パスポートの顔写真と本人の顔の一致をもって「認証」する
(2)チケットカウンターが搭乗券(セキュリティトークン)を発行する
   →搭乗券の中には利用者の名前、便名、座席ランク(トークン)が書かれている
   →チケットカウンターが発行したことを証明するために磁気テープで署名されている
(3)利用者が搭乗券(セキュリティトークン)を搭乗カウンター(RP)に提示する
   →搭乗カウンターは提示された搭乗券が磁気テープ(署名)を見て正しいものかを確認する(信頼された発行元かどうかの確認)
   →搭乗券の中の便名、座席ランクを見て利用者を案内(認可)する


私はこの例はかなりしっくりきました。
みなさんはいかがでしょうか?