2013年6月29日土曜日

[AD FS]Windows Server 2012 R2 Preview の AD FS ①

6月は TechEd 2013 North America があったり、 build があったりとイベントがてんこ盛りで全然ついていけてないのですが、ようやく Windows Server 2012 R2 の Preview が使えるようになったので、予告されていた AD FS の新機能を順番に確認していこうと思います。

尚、AD FS 以外にも多くの機能が Active Directory に追加されているので全体を把握したい人はこちらをご覧ください。
(これはこれで、日本語版のまとめを作る必要がありそうな気がしますが、おそらく Directory Service の MVP の人たちが何とかしてくれるんじゃないかな、と思ってます)

 What's New in Active Directory in Windows Server 2012 R2
 - http://technet.microsoft.com/en-us/library/dn268294.aspx


実はまだ AD FS に関しても細かく見れているわけではないので、とりあえず今回は
・役割の追加と構成
・管理コンソールの中で気になる変化
・ログオン画面の変化
を紹介していきます。

◆役割の追加と構成

とりあえずスクリーンショットを張り付けておきます。尚、今回は Windows Azure の仮想マシンの Windows Server 2012 R2 Preview に日本語言語パックを入れて使っています。また、AD DS を同じマシンにインストール済みです。

途中で KDS ルートキーの設定を求められたので Add-KdsRootKey コマンドレットを使って設定をしたのと、何故か Windows ファイアウォールの規則の生成でエラーが出たのですが放置した、というあたりが特記事項です。

まずは役割の追加です。




次は構成ウィザードの実行です。




こんな警告が出てます。

PowerShell で KDS ルートキーを設定します。






何故か Windows ファイアウォールに嫌われます。


尚、実はこれが今回の AD FS の最大の変化点なんじゃないかな?と思うのが、IIS がいらなくなったという点です。実際 AD FS をインストールしても IIS がインストールされません。
おかげで IIS 管理コンソールを使ってオレオレ証明書を作れなくなったので、別で証明書を作る必要があります。今回は面倒なので Azure の証明書を使ってしまいましたが、マネしないでください。

フォルダ構成を見ても、当然 inetpub/adfs とかは存在せず、C:\Windows の下に ADFS という名前のフォルダがあり、必要なモジュール群はそこにインストールされています。



◆管理コンソールの中で気になる変化

コンソールを立ち上げると、一見見慣れた画面が出てきます。
が、ツリーに存在する「認証ポリシー」という見慣れないメニューが目につきます。

こちらが古い AD FS(Windows Server 2008 R2 時代)


次にこちらが新しいコンソール。「認証ポリシー」というメニューがある。


早速「認証ポリシー」を開いてみると「プライマリ認証」と「他要素認証」というサブメニューが存在します。


それぞれについて編集画面を開くと以下のような設定が出来ます。
・プライマリ認証
 要するにアクセス元によって認証方法を画面から選択できるようになった、ということです。これまでは web.config をいじったりしていた部分です。
 後は、デバイス認証に関する記述があります。これは別途解説が必要なデバイス・レジストレーション・サービス(DRS)という新機能に関連したメニュー(のはず)です。今回のバージョンから iOS なども組織内の Active Directory 上に登録が出来るようになっているので、BYOD を推進するための機能がかなり強化されています。


・多要素認証
 今回の AD FS から他要素認証がデフォルトでサポートされています。まずは他要素認証を適用する条件として、
 ・ユーザ/グループ(特定のユーザ/グループなら多要素認証が必要、など)
 ・デバイス(未登録デバイスなら多要素認証が必要、など)
 ・場所(エクストラネットからのアクセスなら多要素認証が必要、など)
が選択できます。
また、デフォルトでは追加の認証方式として証明書認証だけしか選択できませんが、Windows Azure Active Directory と連携して PhoneFactor を使った SMS や電話、Active Authentication モジュールを使った追加認証もできるようです。



その他、管理コンソールを見ていて気になる点としてはエンドポイントの追加です。
・/adfs/oauth2
・/adfs/portal/updatepassword
とか結構気になるエンドポイントが定義されています。

特に OAuth2.0 のサポートについてはファイルサーバなどのリソースやアプリケーションを Active Directory 上に登録して OAuth2.0 を使って認可する、というシナリオも紹介されていたので、その時に使うものだと思われます。こちらは追って確認してみたいと思います。



◆ログオン画面の変化

試しに手持ちの Google Apps ドメインとの SSO 設定をしてみました。
基本的に設定方法は以前の AD FS2.0 とほぼ変わらないので(他要素認証を証明書利用者信頼ごとに設定が出来るので構成ウィザードで使うかどうか聞かれるくらい)ほぼ問題なく設定は出来ます。

 参考)@IT / Google Appsとのアイデンティティ基盤連携を実現する
 - http://www.atmarkit.co.jp/ait/articles/1301/16/news122.html


で、実際にログオンをしてみるとフォーム認証の画面が一瞬 Office365 や Microsoft アカウントのログイン画面と見間違うようなものに変わっています。


また、多要素認証の設定を入れるとこんな画面になります。(ちなみにクライアント証明書でのログイン設定をしていないのでこの画面で止まりますが)




今回はさわりの部分だけをさらっと見てみましたが、色々と気になる点があるので、引き続き解説していきたいと思います。

2013年6月15日土曜日

[AD FS]Salesforce との SSO(SP-Initiated SSO)

そう言えば何度も AD FS2.0 を使って Salesforce.com へのシングルサインオン設定はやって来ていても IdP-Initiated SSO (先に IdP / AD FS2.0 側で SAML トークンの発行を受けてから SP / Salesforce 側へアクセスする)ばかりで SP-Initiated SSO(Google Apps や Office365 の場合と同様に先に SP / Salesforce 側へアクセスすると IdP / AD FS2.0 側へリダイレクトされて認証、SAML トークンの発行を受ける)のパターンって試していなかったなぁ、、と思ったのでやってみました。

関連)IdP Initiated SSO の手順

 クラウド・サービスと社内システムとのID連携 最新トレンド:
  第5回 Salesforce CRM/Force.comとのアイデンティティ基盤連携を実現する
  - http://www.atmarkit.co.jp/ait/articles/1303/27/news081.html


■作業の流れ

 以下の流れで作業を行います。非常にシンプルです。

 1.[Salesforce側] 組織のドメイン名を取得/設定する
 2.[Salesforce側] シングルサインオンの設定を行う
 3.[AD FS2.0側] 証明書利用者信頼の設定を行う
 4.[Salesforce側] 対象ユーザの設定を行う
 5.[AD DS側] 対象ユーザの設定を行う
 ※今回は Developer Force のアカウントを使っています。

 では、順に解説します。

◆[Salesforce側] 組織のドメイン名を取得/設定する

 管理者で Salesforce にログオンし、[管理者設定]から[私のドメイン]を選択し、組織のドメインを設定します。ドメイン名は<任意の名前>.my.salesforce.com となりますので、任意の名前(重複不可)を設定します。
 しばらく(1日程度)待つとドメインの設定が完了する(管理者のメールアドレスへ通知がある)ので、これで設定は完了です。

 ドメインの設定が終わると以下のような状態になります。(テストが終わったらリリースすることになりますが、今回はテスト状態でも支障がないのでテスト状態のままで進めます)


◆[Salesforce側] シングルサインオンの設定を行う

 同じく管理者でログオンし、[管理者設定]から[セキュリティのコントロール]、[シングルサインオン設定]を選択します。
 そこで[SAMLを有効化]すると SAML 関連の設定が色々と出来ます。
 今回設定した内容は以下の通りです。

項目設定値
SAMLのバージョン2.0
発行者http://<ADFSサーバのFQDN>/adfs/services/trust
IDプロバイダの証明書AD FSのトークン署名用証明書をエクスポートしたもの(cerファイル)
IDプロバイダのログインURLhttps://<ADFSサーバのFQDN>/adfs/ls
SAMLのユーザID種別アサーションには、ユーザオブジェクトの統合 ID が含まれます
SAMLのユーザIDの場所ユーザ ID は、Subject ステートメントのNameIdentifier 要素にあります
エンティティIDhttps://<設定した組織のドメイン>.my.salesforce.com
サービスプロバイダの起動要求バインドHTTP リダイレクト


 設定を完了すると[メタデータのダウンロード]というボタンが出てくるのでクリックしてメタデータ(XMLファイル)をダウンロードします。


 これで Salesforce 側のシングルサインオン設定は完了です。


[AD FS2.0側] 証明書利用者信頼の設定を行う

 次は AD FS2.0 側の設定です。先ほどダウンロードした Salesforce 側のメタデータをインポートして設定を行います。ポイントはただ一つ、利用するセキュア ハッシュ アルゴリズムをデフォルトの SHA-256 から SHA-1 に変更する点だけです。

 まずは、普通通り AD FS2.0 の証明書利用者信頼の作成を行います。
 データソースの選択画面で先ほどのメタデータファイルを選択します。


 作成が終わったら、クレームのマッピングルールを作成します。
 今回は Active Directory の電子メールアドレス属性に入っている値を名前 ID (nameidentifier)として出力します。


 最後に、作成した証明書利用者申請のプロパティからセキュア ハッシュ アルゴリズムとして SHA-1 を設定します。


 これで AD FS2.0 側の設定も完了です。

◆[Salesforce側] 対象ユーザの設定を行う

 次にシングルサインオンするユーザの紐づけをします。
 今回は SAML トークンの中の subject に入っている nameidentifier を Salesforce 上のユーザの統合 ID と紐づけることでシングルサインオンを実現しますので、AD FS2.0 から出てくる nameidentifier に入っている値、つまり Active Directory の電子メールアドレス属性に入っている値を Salesforce 上のユーザの統合 ID に設定する必要があります。

 こんな感じで対象ユーザの属性を編集します。


 次は AD DS です。

◆[AD DS側] 対象ユーザの設定を行う

 同様に Active Directory 上のユーザの電子メールアドレス属性の値を設定します。


 以上で、シングルサインオンの設定および対象となるユーザの設定は完了です。
 早速、試してみます。

 まずは、先ほど設定した Salesforce の組織のドメインのアドレスへアクセスします。
 - https://<組織のドメイン名>.my.salesforce.com

 すると、AD FS2.0 のログイン画面にリダイレクトされ、認証を行います。(例では AD FS2.0 側の Windows 統合認証を無効化しているのでフォーム認証を行います)


 認証が無事に成功すると Salesforce にログオンされます。



いかがでしょうか?IdP Initiated SSO と設定は大きくは変わりませんが、組織のドメインを設定しておけば、Google Apps 等の SP Initiated SSO と同様のユーザ操作でシングルサインオンが実行されるので、組織内に他の SP Initiated SSO で利用しているサービスがある場合は混乱を避ける意味でもこのような設定の方があっている場合もあると思いますので、参考にしていただければと思います。

2013年6月14日金曜日

[FIM2010] FIM ユーザ・グループが始動

流石に日本ではありませんが、オーストラリアの FIM MVP 仲間の Carol Wapshere さんと Bob Bradley さんがやっている「THE FIM TEAM 」という FIM 専門のコンサルティング団体が主催している THE FIM TEAM USER GROUP が立ち上がりました。

 THE FIM TEAM USER GROUP
 - http://thefimteam.com/fim-team-user-group/

メールを送れば誰でも参加できるので、日本の FIM 愛好家のみなさんは是非参加してみてください。

活動としては定期的なオンラインミーティングを予定しているということで、先日第1回が開催されたので早速参加してみました。
残念ながら朝早かったのと、Lync Attendee の調子が非常に悪かったので殆ど何もできませんでしたが、内容的には世界中の FIM User(というかインテグレーション側が多かった印象)がどうやって FIM を使っているのか?という情報を交換する、という感じだったので非常に参考になりました。

当日のレコーディングが YouTube にアップロードされていますので是非ご覧ください。


尚、イベントの中で何個かアンケートがあったので、回答を含め紹介します。
(Carol さんが blog で集計結果を公開しています)

◆本番環境で使っている FIM のバージョンは?
 ・MIIS 2003 : 4%
 ・ILM 2007 : 4%
 ・FIM 2010 : 12%
 ・FIM 2010 R2 : 15%
 ・FIM 2010 R2 SP1 : 65%

 意外とちゃんとバージョンアップしてるんですねぇ。

◆何個くらいのシステムとつないでいる?
 ・1-5 : 10%
 ・5-10 : 35%
 ・10-20 : 50%
 ・20以上 : 5%

 まぁそんなもんかと。

◆使っている同期ルールの種類は?
 ・クラシック(Rule Extension)のみ : 45%
 ・設定(Declarative)のみ : 15%
 ・両方 : 40%

 やっぱりコードレスプロビジョニングだけじゃ何ともならんということです。

◆どのくらいの数のアイデンティティを管理しているか?
 ・1,000以下 : 0%
 ・1,000-5,000 : 3%
 ・5,000-10,000 : 17%
 ・10,000-100,000 : 40%
 ・100,000以上 : 40%

 以外と大規模で使われてますね。数百万という話もチャットの中では出てきました。すごいですねぇ。

◆FIM にかかわる前の技術的なバックグラウンドは何?
 ・運用者 : 50%
 ・開発者 : 30%
 ・その他 : 20%

 やっぱり運用で使い始めて拡大していくパターンが多いんですかね。SIerではなく、ユーザ企業の情報システム部門が自力で実装するケースが多い海外ならではなのかと。

◆FIM にかかわる時間の割合は?
 ・20%以下 : 5%
 ・20-50% : 15%
 ・50-80% : 45%
 ・80%以上 : 35%

 まぁ FIM のグループですから・・・

◆どの FIM のコンポーネントを使っている?
 ・Sync Service
  ・本番環境 : 100%
 ・FIM Servie and Portal
  ・本番環境 : 80%
  ・テスト環境 : 10%
  ・使っていない : 10%
 ・Self Service Password Reset
  ・本番環境 : 55%
  ・テスト環境 : 15%
  ・使っていない : 30%
 ・Certificate Manager
  ・本番環境 : 12%
  ・テスト環境 : 3%
  ・使っていない : 85%
 ・BHOLD
  ・本番環境 : 15%
  ・テスト環境 : 35%
  ・使っていない : 50%
 ・R2 Reporting
  ・本番環境 : 17.5%
  ・テスト環境 : 17.5%
  ・使っていない : 65%

 FIM CM 人気ないですねぇ。。。BHOLD 以下とは。。


MVP の会合以外で中々 FIM の話をどっぷりと聞く機会もないですし、実際に使っている人の話は面白そうなので引き続き参加して情報を共有させてもらおうと思います。



2013年6月12日水曜日

[FIM2010]ついにディレクトリ同期ツールにビルド番号が追いつきました

つい先日、新しいディレクトリ同期ツールに使われている FIM 2010 のビルド番号が本家 FIM 2010 と同一ソースツリーになったらしい、という投稿をしました。


その中で、新しいディレクトリ同期ツールのビルド番号が 4.1.3451.0 、その段階での FIM 2010 R2 のビルド番号が 4.1.3441.0 とお伝えしましたが、昨日 FIM 2010 R2 の HotFix がリリースされ、FIM のビルド番号もディレクトリ同期ツールと同じく 4.1.3451.0 となりました。

 KB ページ


更新内容としては、バグフィックスが2点と久しぶりに FIM CM の機能追加です。
機械翻訳をそのまま持ってきているので妙な日本語ですが、更新ポイントは下記の通りです。

FIM の同期サービス
問題 1
拡張機能 .dll ファイルのキャッシュされたバージョンのパスが長すぎるためパスワード管理操作が失敗します。この問題は、ユーザー マネージャーの Forefront 2010 R2 に含まれている web サービス コネクタも影響します。
問題 2
同期サービスが祖先の処理、特定の状況では、メモリ リークが発生します。
FIM 証明書の管理
機能 1
この更新プログラムは SubjectAltName ポリシーで証明書の要求が発行されると、サブジェクトの別名エントリを RegisteredID の代替名を指定する機能を追加します。
レポート作成
問題 1
Microsoft システム センター サービス マネージャー 2012年サービス パック インストール 1 (SP1)、FIM サービスとポータルのモードの変更のインストールを実行すると、インストールは失敗します。
FIM をレポート サービス マネージャー 2012 SP1 がインストールされている新しいサーバーにインストールすると、次の手順を実行します。
FIM 2010 R2 SP1 の FIMService コンポーネントをインストールします。これを行うには、レポートのチェック ボックスをオフにします。
4.1.3451.0 をビルドするのには、FIMService のインストールをアップグレードします。
モードの変更のインストールは FIMService を実行し、レポートを追加.


後は今月プレビューがリリースされる予定の Windows Azure Active Directory Connector を待つのみですね!

尚、以前紹介したビルド番号一覧にも今回のリリースを反映しておきましたので、歴史を確認したい人はどうぞ。

 [FIM2010]各リリース毎のビルド番号

2013年6月7日金曜日

エンタープライズロール管理解説書(第1版)がJNSA IdM-WGよりリリース

私がお世話になっている JNSA (日本ネットワークセキュリティ協会)の アイデンティティ管理ワーキンググループより
 エンタープライズロール管理解説書(第1版)
がリリースされました。

ロール管理、という実際に IdM プロジェクトを進める時は鬼門になりやすいテーマでの議論だったので、主要執筆メンバの方々はかなり苦労をされていたように感じます。(2年越しの議論でした)

以下の URL から無償でダウンロードできるので、ぜひダウンロードしてみてください。

ダウンロードページの紹介分より
本書は「エンタープライズロール管理」について、その基礎となる考え方や実施の意義、ID管理システムを導入するにあたって同時に検討すべき「ロール管理」について、実用的な導入指針(ガイドライン)を示している。本書の作成にあたったワーキングループには、ID管理製品やロール管理製品の開発・販売ベンダー、導入経験のあるSIer・コンサルタント等が多数参加しており、特定の製品に偏向しないことを留意しつつも、ロール管理を導入するユーザ、SIer等にとって有用となる知識・ノウハウを持ち寄った。
その結果、本書はロール管理とは何か?から始まり、ID管理におけるロール管理の重要性を解説し、実際のロール管理の実装ステップをステップ毎に解説をおこなっている。また、ロール管理はその運用が重要になるため運用のガイドラインとなるものを解説した。
これから、ロール管理を導入検討する人には、プロジェクトの推進の準備として、また、現在ID管理やロール管理システムを導入中の人にとっては、現在のプロジェクトをよりよくするためのチェック、ヒント集として、活用していただけると考えている。
なお、本書は「日本ネットワークセキュリティ協会(JNSA)」の「アイデンティティ管理ワーキンググループ」にて数年に渡って検討した内容となっており、ワーキンググループに参加いただいたすべての方々のご協力に深く感謝する。
また、この分野について詳細に書かれた書籍がほとんど出版されておらず、その意味でも本書の内容は多くの企業に役立つ内容となっている。
本書があらゆる企業において、ロール管理の適切な導入・運用に貢献できれば幸いである。




尚、発売について先日紹介したものの一時的に Amazon のリンクが切れていた「訂新版クラウド環境におけるアイデンティティ管理ガイドライン」ですが、昨日より復活しているのでこちらも是非見てみてください。
(Kindle版の発売が決まったのと、紙媒体版の価格が少し上がっています(3200円⇒3360円)




[Office365]新ディレクトリ同期ツールはFIM2010R2ベース

6月頭にリリースされた新しいディレクトリ同期ツールを触ってみています。

一番大きな変更点はオンプレミスの Active Directory から Windows Azure Active Directory へのパスワード同期が可能になった点ですが、少し細かい部分を掘っていこうと思います。

尚、全体的な動作やセットアップ方法などは Office 365 MVP の渡辺元気さんが書いているのでそちらが参考になります。

 日々徒然 ディレクトリ同期ツールでパスワード同期
  http://blog.o365mvp.com/2013/06/05/dirsync_with_password_sync/

また、パスワード同期については Technet にドキュメントが公開されているので、こちらも参考になります。

 Implement Password Synchronization
  http://technet.microsoft.com/en-us/library/dn246918.aspx



ディレクトリ同期ツール(FIM)がどうやって Active Directory からクラウドへパスワードを持っていっているのか?についてはもう少し深堀をしている最中なので、いずれ紹介していければと思います。
少なくとも現段階でわかっているのは、
 ・PCNSを使っているわけではない(ドメインコントローラにモジュールを入れる必要はない
 ・Active Directory Connectorを使ってパスワード属性をMetaverseにマッピングしているわけではない(Metaverse、Connector Spaceにパスワード属性は入らない)
ということから、おそらく Windows Azure Active Directory Connector(ECMA2ベース/Microsoft.Azure.ActiveDirectory.Connector.dll)のExtensionの中、もしくは Metaverse の Extension(MSONLINE.MVExt.dll)の中で定期的にパスワード変更を監視して、Active Directory のデータベース(ESE)から直接ハッシュ化された状態のパスワードを抽出しているのだと思われます。(もしくは Active Directory Connector がやっているみたいに Directory の Replication で変更を抽出しているかも。こっちの方が有力です)


と、パスワードに関してはこのくらいですが、もう一つ大きな更新ポイントは内蔵されている FIM のバージョンが変わった点です。
これまでは無印 FIM 2010 ベースでしたが、今回から FIM 2010 R2 ベースにかわっています。

以前のディレクトリ同期ツール




新しいディレクトリ同期ツール


ビルド番号を見ると 4.1.3451.0 となっており、現状の最新の FIM 2010 R2 SP1(4.1.3441.0)のビルドラインに乗っているように見えます。以前は 5.x 台となっており本家の FIM 2010 とは別のソースツリーになっているように見えましたが、ここにきて同じラインになった(様にみえる)、ということは本家 FIM 2010 でも Windows Azure Active Directory Connector がリリースされる日も近いのかも知れませんね。
と、思ったらTechEd North Americaで発表されてました。6月からパブリックプレビューだそうです。