[Windows10]Intel RealSense F200でWindows Hello

ついに2015/07/29にリリースされる発表されたWindows10ですが、やはり気になるのはWindows Helloによる生体認証です。

そして今回は最新のInsider PreviewでWindows Helloを試して玉砕した話です。

これまで中々Preview版に搭載されてこなかったので、どのようなデバイスが対応するのか？どのように動くのか？については情報が少なかったのですが、Build 10130でようやく実装されてきました。
　公式blog
　https://blogs.windows.com/bloggingwindows/2015/05/29/announcing-windows-10-insider-preview-build-10130-for-pcs/

なお、私は以下のPOSTを信じてIntel RealSense 3D Camera F200の開発者キットを購入済みでした。
　公式blog
　https://blogs.windows.com/bloggingwindows/2015/03/17/making-windows-10-more-personal-and-more-secure-with-windows-hello/

We’re working closely with our hardware partners to deliver Windows Hello capable devices that will ship with Windows 10 and we are excited to announce that all OEM systems incorporating the Intel® RealSense™ 3D Camera (F200) will support the facial unlock features of Windows Hello, including automatic sign-in to Windows, and support to unlock “Passport” without the need for a PIN.

http://click.intel.com/intel-realsense-developer-kit.html


さっそくHelloの設定を！と思いましたが、肝心のセットアップボタンが出てきません。

カメラがうまく認識されていないのか、と思いF200のSDKに付属のユーティリティで赤外線カメラの動作状況を確認してみます。

うまく動いているようです。ひどい写真・・・

ちなみにWindows Helloの生体登録画面を検索機能で直接呼び出すこともできるので直接起動してみると無反応の黒い画面が起動します。
（英語版でBio Enrollmentという名前のアプリケーションです。しばらく前からこれは何なんだ？？って某所で話題になっていたやつです。「生体登録」という名前で検索すると起動できます）

ちょっと状況を確認してみましょう。

まずはイベントログを見てみます。
対象のログは「アプリケーションとサービスログ\Microsoft\Windows\BiometricsのOperational」です。
初期状態ではログが無効化されているので有効にしてOSを再起動するか、ローカルサービスより「Windows Biometric Serive」を再起動するとデバイスの再認識が走るので状況が記録されます。

初期化に失敗しているようですね。
さらに深堀してみましょう。

レジストリエディタを開いて該当するエントリを探します。
ありました。
HKLM\SYSTEM\ControlSet001\Services\WbioSrvcです。

顔認証をさせたかったので、FacialFeaturesのVirtual Sensorsあたりを見るとモジュール情報が入っていますが、SerialNumberがTBDとかおしゃれな感じです。さらに探っていくと、DatabaseIdというエントリが見つかりました。

これがWbioSrvc直下のDatabases以下のエントリと紐づいているようです。実際にDatabasesの該当するキーを見るとFilePathで物理ファイルとの紐づきを管理しているようです。

ここまで来これば、直接ファイルの状態を見てみるしかありません。

・・・ありませんでした。
登録に失敗しているのですから当然ですね。

と、あまり実りのないことを深堀りしましたが、その後Intelの開発者フォーラムで以下のPOSTを発見しました。
https://software.intel.com/en-us/forums/topic/559166

Q: Curious if this camera with drivers installed compatible with Windows Hello in the latest builds of Windows 10?
   If it is - any tricks to making it work?
A: It's not yet. With the next DCM release for the user facing camera and SDK version, it is planned to be supported.

なるほど。次のバージョンのDCM（Depth Camera Manager）を待て、、と。

とりあえず顔認証はしばらくお預けですね。

ちなみに、私の周りの方の試したデバイスと結果は以下のような感じです。
・Lenovo ThinkPad X1 Carbon内蔵指紋認証デバイス　：　○
・UPEK Eikon USB外付け指紋認証デバイス　：　○
・RATOC SREX-FSU2　：　×
・Kinect/Kinect v2 ：　×

なかなか厳しいですね。
LenovoのPCなど指紋認証デバイスがついているPCではちゃんとWindows Helloが動いているようなので、おそらくこのままバグフィックスをして製品としてはローンチされるんですかね。Intelの対応が待ち遠しいです。

[FIDO/Windows10]idcon vol.20（別名fidcon）が開催されました

先日のポストで紹介させていただいた通り、Identity Conference / idcon の記念すべき20回目が開催され、私も Windows 10 の FIDO（First IDentity Online）実装である Microsoft Passport および Windows Hello について話をさせていただきました。

参考）
　Identity Conferenceのページ
　https://idcon.doorkeeper.jp/events/23320

　FIDO Allianceのページ
　https://fidoalliance.org/


◆当日の流れと様子
詳しくは @nov さんが togetter にまとめてくれていますが、当日は以下の順番で講演が行われました。

1. Token Binding と FIDO / レピダム 前田さん（@mad_p）

Tokbind-fido from Kaoru Maeda

OAuth の Token や Cookie などの Bearer Token はその名の通り、Bearer（持って来た人が使えてしまう）なトークンなので、認証等のセキュリティが求められるトランザクションには不向きです。Token Binding は Token を行使できる相手の ID と Token を関連付けて管理していこう、という取組みです。今回前田さんに紹介いただいたのは tls-unique を使って TLS セッションと Token を関連付け、TLS セッションが生きている間は Token を有効にする、という仕組みでした。
また、この Token Binding を安全にやり取りする仕組みとして、id_token 内に入れて署名する方法や、今回のテーマでもある FIDO を使って署名する方法が紹介されました。


2. FIDO in Windows 10 / ふじえ（@phr_eidentity）

FIDO in Windows10 from Naohiro Fujie

2番目が私のパートでした。
基本的にはこれまで本ブログで書いてきたことばかりではありますが、マイクロソフトが Windows 10 と Microsoft Azure Active Directory で目指している True SSO 環境＝「どこからでも、どんなデバイスからでも、デバイス～アプリケーション間での SSO を実現できる環境」と構成する要素である Microsoft Passport / Windows Hello の概要の説明、そして Azure AD Join を行った環境におけるデバイス登録～ログイン～アプリケーション利用までのフローの解説をさせてもらいました。
FIDO との関係としては、デバイスの登録およびPCへのログインの部分の仕組みが正に FIDO、そのあとのアプリケーション利用の仕組みは OpenID Connect ってあたりです。


3. Yahoo! JAPAN の FIDO への取り組み / ヤフー 五味さん

Idcon gomi-052715-pub from Hidehito Gomi

このセッションが一番最初だったら良かったんじゃ、、と思いました。
パスワードの課題～ FIDO の概要・仕組みに関する説明が抜群にわかりやすかったので、このスライドを見た後に、Azure AD Join のフローを見るとどこが FIDO なのか？についてより理解できると思いました。
FIDO の本質はデバイス登録～信頼により、認証サーバが登録済みデバイスによって行われたユーザ認証結果を信頼する、という流れでユーザ認証に関するやり取りがネットワーク上を流れなくする＝クレデンシャルを保護しやすくなる、というのが一番のキモですね。


4. パスワードレス認証 M-Pin の概要 / CertiVox 尾崎さん

NTTソフトさんの Trust Bind との組み合わせソリューションとして最近日本でも活動を始めた英国の CertiVox 社のパスワードレス認証の仕組み「M-Pin」の紹介でした。
FIDO のような標準化を目指した仕組みではなく、独自の仕組みではありましたが、銀行 ATM の暗証番号入力のようなユーザ・インターフェイスは使いやすそうで、一般の利用者に多要素認証を使わせるにはハードルが低いのではないか？と思いました。

https://www.certivox.com/





◆おまけ
ちなみに、セッションを引き受けた時は Windows Hello が5月末には使えるようになっているだろうなぁ、、、という微かな期待の元、インテルの Real Sense （3D/赤外線カメラ）を買って準備していたんですが、残念ながらセッション当時リリースされていた Windows 10 Technical Preview Build 10074 / 10122 ではまだ Windows Hello は実装されていませんでした・・・。昨日あたらしく 10130 がリリースされていたので、そちらで試してみてまた別途レポートします。。

製品ページ
　http://www.intel.co.jp/content/www/jp/ja/architecture-and-technology/realsense-overview.html
Amazon
　http://amzn.to/1LPbBbW

[FIM/MIM]CTP4へのインプレースアップデート（Sync Engine編）

4月下旬にconnectサイトにリリースされたMicrosoft Identity Manager 2016 CTP4ですが、今回のバージョンからインプレース・アップデートに対応しています。
※現状FIM CMについてはバグがありアップデート出来ないようですが。

参考）
　[MIM]新しいPublic Previewがリリース、MIM2016へ
　http://idmlab.eidentity.jp/2015/04/mimpublic-previewmim2016.html

今回はSynchronization Serviceのインプレース・アップデートを行ってみます。

◆結果
今のところ何の問題もなく、HotFixを適用するのと同じ程度の手間でアップデートが出来ました。
（特にSyncエンジンは殆ど何も変わっていないので、当たり前ですが）
また、ECMA2で作成したGeneric REST MAについても簡単な確認をした限りでは問題なく使えていそうです。


◆アップデート手順
まず、アップデート前のバージョンを確認しておきます。

2つ前のHotFixが適用されたForefront Identity Manager 2010 R2 SP1（FIM2010R2）ですね。

早速connectからダウンロードしたCTP4を解凍し、Synchronization Serivceフォルダ以下のsetup.exeを実行します。

ちゃんとUpdateとして認識してくれているようです。

まだ、バージョン番号がMicrosoft Identity Manager 2015のままですね。

アップデートなので基本的な設定は引き継いでくれます。

色々と注意事項がでますがセットアップを継続です。

セットアップはすぐに終ります。
特に問題なくセットアップフェーズは進みました。


◆確認
早速Synchronization Managerを起動します。

起動時のロゴがMicrosoft Identity Managerになっていますね。

しかし、バージョン情報を見ると相変わらずFIMのままです。
ビルド番号は流石に4.1.1790.0と新しくなっていますが。

この状態で簡単に管理エージェントを動かしてみましたが、特に問題なく動きました。

ここまでです。Synchronization Serviceについては何の問題もありませんでした。

次回はFIM Servive/Portalのアップデートをやってみまたいと思います。
（こちらはそれなりに変な動きをしてくれています。流石にモジュール構成の変更が多いので難しい部分だったのだと思います）

[Build 2015]アイデンティティ関連セッションリスト

4月～6月にかけて海外では各種イベントが続々と開催され、アイデンティティに関しても新しい情報が出てきたりするので目が離せません。

・Microsoft
　Build 2015
　http://www.buildwindows.com/

　Ignite 2015
　http://ignite.microsoft.com/

・Kuppinger Cole
　Europian Identity & Cloud Conference 2015(EIC 2015)
　https://www.id-conf.com/

・Ping Identity
　Cloud Identity Summit 2015
　http://www.cloudidentitysummit.com/


今回は先日サンフランシスコで開催されたMicrosoftのBuild 2015よりアイデンティティ関連のセッションをピックアップしました。
スライドとビデオが公開されているので、Azure Active Directory（AzureAD）、Office365 API、Windows 10のPassport/Windows Hello関連に興味のある方は必見です。

◆AzureAD連携アプリケーション開発関連
Azure Active Directory: Identity Management as a Service for Modern Applications
http://channel9.msdn.com/Events/Build/2015/2-738

Cloud Authentication Troubleshooting and Recipes for Developers
http://channel9.msdn.com/Events/Build/2015/2-740

Develop Modern Web Applications with Azure Active Directory
http://channel9.msdn.com/Events/Build/2015/2-753

Develop Modern Native Applications with Azure Active Directory
http://channel9.msdn.com/Events/Build/2015/2-769


◆AzureADとOffice365 API関連
Get Your Hands Dirty with the Office 365 APIs, Authentication and SDKs
http://channel9.msdn.com/Events/Build/2015/4-630


◆Passport/Windows Hello関連
Single Sign-On with Secure Authentication
http://channel9.msdn.com/Events/Build/2015/2-709

Managing Mobile Devices and Applications in an Enterprise
http://channel9.msdn.com/Events/Build/2015/3-654

Microsoft Passport and Windows Hello: Moving Beyond Passwords and Credential Theft
http://channel9.msdn.com/Events/Build/2015/2-639

Building Universal Windows Apps with Office 365 APIs
http://channel9.msdn.com/Events/Build/2015/3-767

App-to-App Communication: Building a Web of Apps
http://channel9.msdn.com/Events/Build/2015/3-765



尚、セッションデータを一括ダウンロードするスクリプトが公開されているので、上手く活用をして効率的にマテリアルをダウンロードすると良いでしょう。
https://gallery.technet.microsoft.com/All-Videos-and-Slides-from-64a86489

ちなみにこのスクリプト（というよりもChannel9のRSSフィード）には不具合があり、一部修正が必要です。

以下のステップで修正をします。
１．RSSフィードを直接ダウンロードする
　　以下のURLをブラウザで直接開いて表示された内容を保存します。
　　http://channel9.msdn.com/Events/Build/2015/RSS/slides

２．ダウンロードしたフィードを修正する
　　1287行目のitunes:summaryの行に不具合があるので、この行を丸ごと消してしまいましょう。

３．スクリプトがローカルにダウンロード・修正したRSSフィードを読み込むように修正する
　　ダウンロードしたスクリプトがインターネット上のRSSフィードではなく、上記２で修正したフィードを読み込むように以下の様に修正します。
　　（修正前）

　　（修正後）

後は保存してPowerShellを実行すればごっそりファイルのダウンロードが出来ます。
※スライドだけでも1.7GBくらいあるので空き容量に注意が必要です。

[Windows10]デバイス＆サービス間のシングルサインオンの仕組み

※ご注意
・現在公開されている情報＋Fiddler等でWindows10の動きを解析した結果からの推測です。
　（そのうちMSDNあたりに確かな情報も公開されると思います）
・Windows10 Insider Preview（Build 10074）をベースに確認しています。
・細かい話は今月末（5/27）に開催されるidcon（別名fidcon）で話をする予定です。



今回はこれまで紹介してきたWindows10のクラウド・ドメイン参加（Cloud Domain Join/CDJ）によるPCログオンとOffice365等のアプリケーションの間のシングルサインオンの動作の仕組みについて考えてみます。

その前におさらいです。

◆CDJとは
簡単にいうと、Windows10のデバイス（PC）へのログオンにAzure Active Directory（AzureAD）を使う、つまりオンプレミスのActive Directoryへのドメイン参加ではなく、クラウド上のAzureADへドメイン参加する機能のことです。

＜関連ポスト＞
　[Windows10/AAD]クラウド・ドメイン参加を試す
　http://idmlab.eidentity.jp/2015/02/windows10aad.html

　[Windows10/AAD]OOBEでクラウド・ドメイン参加
　http://idmlab.eidentity.jp/2015/03/windows10aadoobe.html


◆CDJを使ったTrue SSOとは
これまでWebアプリケーション間のSSOはAD FSやAzureADなどSAMLやws-federationの実装により割と容易に実現出来ました。また、社内のPCの様にActive Directoryドメインに参加している環境においてはAD FSへの統合Windows認証をすることによりPCログオンとWebアプリケーションとの間でのSSOを実現してきました。
しかし、あくまで統合Windows認証に依存する仕組みのため、社外からのアクセスなどドメイン・ネットワークの境界を超えると途端にSSO出来なくなる、という非常に限定的な仕組みでもありました。

しかし、CDJを使いPCログオンをAzureADで行うことによりドメイン・ネットワークの境界の外にある社外PCについてもPCログオンとWebアプリケーションのSSOを実現することが出来るようになりました。

＜関連ポスト＞
　[Windows10/AAD]Technical Preview Build 10041のCDJでOffice365とのSSOを実現
　http://idmlab.eidentity.jp/2015/03/windows10aadtechnical-preview-build.html

　※ちなみにBuild 10074ではOffice365とのSSOは上手く動かず、代わりにAzureの新管理ポータル（https://portal.azure.com/）へSSO出来るようになっています。



さて、本題です。
では、CDJを使いWindows10のPCではどのようにデバイスとアプリケーションの間のSSOを実現しているのでしょうか？

CDJではざっくり言うと以下の処理が実行されます。
①AzureADへのデバイス登録
　⇒秘密鍵のダウンロード、TPMへの保存
②ユーザ認証
　⇒秘密鍵を使ってAzureADからプライマリ・リフレッシュ・トークン（PRT）の取得
③アプリケーションへのアクセス
　⇒AzureADでPRTをアクセス・トークンへ交換し、アプリケーションへ提示

PINや顔認証でPCにログインできるようになるのは、CDJでAzureADの信頼済みデバイスとして登録された後、TPM上にストアされた秘密鍵にアクセスすることが出来ることでユーザを認証することが可能なためです。
（この秘密鍵にアクセスするためのパスフレーズとしてPINやバイオメトリクスを使っているのが噂のWindows Helloです）


このあたりは、先日のJapan SharePoint Groupでデモを交えつつ話をした内容です。
当日のスライドはこちら。後半でNext Generation Credentials/NGC（現在はPassportって言ってるやつです）のフローを解説しています。

Microsoftの認証システムの歴史と 過渡期におけるWAPの活用 +Next Generation Credentials from Naohiro Fujie

特にこの辺のスライドですね。

で、実際SSOを実現するには、この中で出てくるPRTをアプリケーション向けのアクセス・トークンに交換する必要がありますが、この部分を担当しているコンポーネントがWindows10から導入された「Web Account Manager」および「AAD Token Broker Plugin」です。

Web Account Managerは現在.NETやJava Script向けに提供されているActive Directory Authentication Library（ADAL）の後継（？）となるコンポーネントで、バックエンドで認証やアクセストークンの取得などの処理を行うものです。ただ、ADALが各アプリケーションに組み込むライブラリとして提供されていたのに対して、Web Account ManagerはWindows10/Windows Phone10に組み込まれた独立したモジュールとなっています。

OpenID ConnectのRPとして実装されたWebアプリケーションは、AzureAD上に登録する必要があり、登録の際のredirect_uriに「ms-appx-web://Microsoft.AAD.BrokerPlugIn/[アプリケーションのsid]」を指定することでWeb Account Managerを呼び出すことが出来ます。（ネイティブアプリケーションからはRequestTokenAsyncなどのAPI経由で呼び出します）

Build 2015のセッションより

単純にWeb Account Managerを使うだけだとAzureADで個別に認証をしてアクセス・トークンを受け取る必要がありますが、先にCDJで取得したPRTがあると、AAD Token Broker PluginがPRTをAzureADへ渡してアクセス・トークンを取得するのだと思われます。

これで、PCへのログオンとWebアプリケーションへのログオンのSSOの出来上がりとなります。


ちなみにAzureAD上にリソースとして登録していないWebサイトからの認証要求が来ると、AADのイベントログにID1098、1097が記録されるので、PRTの交換に失敗していることがわかります。

一番上にも書きましたが、5/27のidconでもう少し深く仕組みの紹介をしたいと思います。
※CDJの各フェーズで実際にどのような通信が発生しているのかをfiddlerで可能な限り取得した結果などもお見せできれば、、と思います。仕組み上、ログイン中に発生している通信も多いので、全部がトレースできる訳ではありませんが。。。

[AD FS]Windows Server Technical Preview 2のAD FSファーストレビュー（管理GUI編）

先日第2弾が公開された次期Windows ServerのTechnical PreviewのAD FSがどう変わったのか確認してみたいと思います。

第一印象ですが、かなり便利・かつ高機能になっている印象です。

私なりのポイントですが、以下の5点だと思います。（まだ触り切れていないのでどこまで使えるかは微妙ですが）

1. PowerShellでしか出来なかった操作がかなりの範囲でGUIで操作できるようになった（OAuthのクライアント登録とかScope登録とか）
2. OpenID Connect Discoveryに対応した（限定的ではありますが）
3. Microsoft Azure MFAが最初から組み込まれた
4. VPNアクセス用の証明機関としての機能が付いた（？）
5. Web Application Proxyの管理GUIが統合された（？）

※？マークはそれっぽいメニューが存在するだけなので、どう動くのかはまだわかっていません。

また、結局Blogには投稿できませんでしたが、前回のPreviewから

• OpenID Connectへの対応
• OAuth2.0への対応の改善（Implicit、Client Credentialへの対応）

がなされています。
（検証結果をまとめている時間がなかっただけなので、まとめたら改めて公開したいと思います）


ということで今回は管理ツール周りを見ていきたいと思います。

◆メニュー構成
管理GUIの左ペインを見ると以下の5項目でメニューが構成されています。

• Service
• Access Control Policies
• Relying Party Trusts
• Claims Provider Trusts
• Clients

Windows Server 2012R2では

• サービス
• 信頼関係
• 認証ポリシー

の3項目でした。
サービスはそのまま、以前は信頼関係メニューの中にあったRelying Party Trust（証明書利用者信頼）とClaims Provider Trusts（要求プロバイダー信頼）がトップレベルに昇格、Access Control PoliciesとClientsが新規に追加され、認証ポリシーが消えた、という感じです。

では、それぞれ順番に見ていきます。


◆Serviceメニュー
以下の9項目のサブメニューで構成されています。

• Attribute Store
• Authentication Methods
• Certificate Authority
• Certificates
• Claim Descriptions
• Device Registration
• Endpoints
• Scope Descriptions
• Web Application Proxy

それぞれ簡単に解説しておきます。

Attribute Store

以前は信頼関係の配下にあったものが移動されています

Authentication Methods

以前はトップメニューにあった認証ポリシーがServiceの配下に来ています

Certificate Authority 

新規に追加された項目です。VPNアクセス用の証明書の発行をする機能のようです。

• Certificates
• 変化なしです。
• Claim Descriptions
• 変化なしです。
• Device Registration
• 新規に追加されています。Windows Server 2012R2ではPowerShellで設定していたものがGUIで出来るようになっています。（前回のPreviewより）

• Endpoints
• 変化なしです。
• Scope Descriptions
• 新規に追加されています。OAuth/OpenID ConnectのScope設定が出来ます。これも以前はPowerShellで設定していたものがGUIで出来るようになっています。

• Web Application Proxy
• 新規に追加されています。WAPを構成した場合にここで管理できるようになるのかも知れません。

◆Access Control Policiesメニュー
新規に追加されたメニューです。
これまでClaimルールで頑張って書いていたような認可ポリシーがある程度テンプレートとして用意されています。

◆Relying Party Trustsメニュー
あらかじめ以下のRelying Partyが定義されています。

• VPN Server（無効化状態）
• UserInfo

Windows Server 2012R2ではここにDevice Registration Serviceが登録されていましたが、初期状態では存在しません。
また、ここにはSAMLやws-federationのRelying Partyだけではなく、OAuthの保護リソースも登録されるため、OpenID ConnectのUserInfoがここに最初から登録されています。


◆Claims Provider Trustsメニュー
ここは何も変わりません。初期値ではActive Directoryだけが登録されています。

◆Clientsメニュー
新しく出来た項目です。
ここで、OAuthのクライアント管理を行うことが出来ます。
ちなみに、Windows Server 2012R2ではPublic Clientしか登録することが出来ませんでしたが、次期バージョンからはConfidentialも登録できるようになっています。（つまり、client_secretの発行が出来、Client Credentialなどのフローで使えます）

初回なので、今回はここまでにしておきますが、次回以降でもう少し細かい部分や動きを確認していきたいと思います。

【参考】
　Windows Server Technical Preview 2のISOファイルやVHDファイルは以下よりダウンロードできます。
　　https://technet.microsoft.com/ja-jp/evalcenter/dn781243.aspx
　※もしくはMicrosoft Azure上で仮想マシンとしての提供されていますので、そちらを使うことも可能です。
　　今回は手元にISOファイルから新規インストールしました。

　尚、最初に公開されたバージョンのTechnical PreviewのAD FSについては以下のポストで紹介しています。
　[AD FS]Windows Server Technical Previewで追加された機能～PowerShell編
　　http://idmlab.eidentity.jp/2015/03/ad-fswindows-server-technical.html
　[AD FS] Windows Server Technical PreviewのAD FSを試す
　　http://idmlab.eidentity.jp/2014/10/ad-fs-windows-server-technical.html

[FIM]最新HotFixでPCNSがようやくWindows Server 2012 R2に対応

ようやくPCNS（Password Change Notification Service）がWindows Server 2012 R2のドメインコントローラに対応しました。

これでPCNSがネックでドメインコントローラをWindows Server 2012 R2へアップデート出来なかった人たちも一安心です。（どれだけいるかは・・・ですが）

ちなみにPCNSは、Active Directoryドメイン上の全ドメインコントローラ上にインストールするモジュールで、各PCや管理者によるActive Directoryのパスワード変更をフックしてFIMに通知・連携するためのモジュールです。これを使うとctrl+alt+delなどで変更したパスワードをFIMと連携している他のアプリケーションへも連携することが出来ます。

今回のForefront Identity Manager（FIM）のHotFixでは実際にPCNSのモジュールが更新されているわけではなく、FIMに同梱されているActive Directory Management Agentが更新されているところを見ると、これまでもWindows Server 2012 R2からのパスワード変更通知は受け取れていたようですが、（おそらくパスワード自体の）ハンドリングが上手く出来ていなかった、というあたりを改修したように思われます。
（パッチのリリースノートを見ても、PCNSからの通知をFIM Synchronization Serviceが受け取った際のLsaLookupNames2 APIをコールする際のドメイン・フォーマットに起因する不具合の修正が含まれていますので、このあたりがWindows Server 2012 R2対応した部分だと思われます）

他にもFIM Sync/FIM CM周りでも修正は入っているようなので、現在FIM 2010R2 SP1を運用している方は早めの適用が推奨されています。


◆前提/注意事項
と、ここまで書きましたが、今回のHotFix適用にあたり、以下の注意事項があります。

1. Windows Server 2012 R2に対応したのはあくまで「PCNS」
• ⇒FIMを導入するサーバはWindows Server 2012無印までしか対応していません。MIMを待ちましょう。
2. カスタムの管理エージェントを導入している人は互換性に関する不具合が出ることがあります。
• 管理エージェントをコンパイルした時のMicrosoft.MetadirectoryServicesEx.dllのバージョンによってはno-start-maエラーが出る場合があるので、その場合は.configファイルにバージョン互換に関する記載を追記しましょう。詳細はHotFixのダウンロードページに記載されています。
• ちなみに私の環境では拙作Generic REST API Management Agentは何もしなくても問題なく動きました。

- HotFixダウンロードページ
　https://support.microsoft.com/en-us/kb/3048056
- HotFix適用によるビルド・バージョン
　FIM　： 4.1.3634.0
　BHOLD　： 5.0.2959.0