[MIM]特権アカウント管理機能の概要

リリース目前のMicrosoft Identity Manager（MIM）ですが、なんといっても目玉機能は特権アカウント管理機能（Privileged Access Management / PAM）です。

以前のポストでどのような動きになるのか動画を紹介しましたが、今回は具体的な中身についてみていきたいと思います。

　参考）[MIM]特権アクセス管理のデモ動画
　http://idmlab.eidentity.jp/2015/04/mim.html


◆PAMで何ができるのか？

　現段階のリリース予定では、「Active Directoryの特権アカウントの管理」が可能になります。
　当然これまでもセキュリティ・グループへの追加・変更・削除は出来ましたが、
　　・時間制限付きのメンバシップの管理
　　・申請～承認のフロー
　　・多要素認証の要求
　　・履歴管理
　といった、実際に特権アカウントを管理する上で必要な機能をパッケージ化しています。


◆どのように実現しているのか？

　キーとなるのは以下です。
　・片方向の信頼関係
　・シャドーグループによるSID-Historyによる特権の紐づけ

　簡単に図示したのが以下の図です。

　通常、ドメインの移行をする際にリソースへのアクセスを維持するために使用するSID-Historyを使って、業務用ドメインの保護対象リソースへアクセスできるセキュリティ・グループと特権管理ドメイン上に作成した特権ロールの紐づけを実現します。
　このことにより、MIMが特権ロールのメンバシップを更新することにより実際には業務ドメイン上のグループに所属していないユーザでも一時的に保護対象リソースへアクセスすることが可能になります。

　MIMのPAM機能のロール管理は以下のような構造になっています。

◆どのように動くのか？

１．特権を付与する前の保護対象リソースへのアクセス

　今回は単純に共有フォルダへのアクセスをさせてみます。
　特権付与前の状態だと「アクセスが拒否」されます。

２．特権申請をする

　今回はMIMにサンプルで付属している特権管理ポータルを使い、ロールの利用を申請します。
　（REST APIを直接たたいて申請する方法もありますし、申請用のアドオン、PowerShellのコマンドレットが付属しています）
　単純にロール名を選択して[Elevate]をクリックします。

　すると要求の詳細（申請理由と期限）が入力できるので必要であれば入力してSubmitします。

３．申請を承認する

　今度は管理者で特権管理ポータルへログインし、承認を行います。
　誰から、何のために、どのくらいの期限で、という申請情報が来ているので[Approve]をクリックして承認を行います。

４．再び保護対象リソースへのアクセス

　特権申請をしたユーザで新しいセッションを開始して、自身が所属しているグループを確認すると、特権ドメイン上の特権グループおよび業務ドメイン上のグループのメンバになっていることがわかります。

　また、この状態であれば当然、共有フォルダへのアクセスが可能となっています。

　※今回共有フォルダへのアクセスを例にしたため、PCログインのセッションが残っているので、セッションを切り替えるためにrunas等で新たに特権申請したユーザでのセッションを作成しなおす必要がありましたが、Webリソースなど都度ログインするようなアプリケーションであれば、都度権限チェックがなされるため本当に期間限定でリソースへのアクセスができるように見えます。

５．申請期限後に再び保護対象リソースへのアクセス

　申請した有効期限が過ぎてから再度リソースへアクセスすると最初と同じくアクセスが拒否されます。また、メンバとなっているグループを見ると特権グループから外れていることがわかります。

　ちなみにMIM側のジョブの走るタイミングによると思いますが、期限が切れるタイミングと実際にグループメンバから外れるタイミングには数分のタイムラグがあります。



次回以降、環境の構成方法などもう少し細かい方法を解説していきたいと思います。

[AzureAD]AAD ConnectとConnect HealthがGAになりました

ついにAzure AD ConnectとConnect Healthが一般公開されました。

公式blog）Azure AD Connect & Connect Health is now GA!
　http://blogs.technet.com/b/ad/archive/2015/06/24/azure-ad-connect-amp-connect-health-is-now-ga.aspx

それぞれを一言で紹介すると以下の通りとなります。

モジュール	解説	主な機能
Azure AD Connect	Azure ADとオンプレミスADのハイブリッド構成（SSO、ID同期）を構成するためのツール群	AD FS/AAD Syncの簡単設定機能 マルチフォレストAD連携、非ADのオンプレミスIdPとのID同期
Connect Health	AD FSのモニタリングツール	リクエスト数、ログインエラー数などのモニタリングとグラフィカル表示

今回はAAD Connectの方を中心に紹介したいと思います。


◆AAD ConnectのリリースによりDirSyncおよびAAD Syncの個別リリースが終了

重要なポイントですがAAD Connectがリリースされたことにより、DirSyncおよびAAD Syncについては今後個別のモジュールとしてリリースされることはありません。今後はAAD Connectの更新として提供されることとなります。

Azure AD Connect incorporates the components and functionality previously released as Dirsync and AAD Sync. These tools are no longer being released individually, and all future improvements will be included in updates to Azure AD Connect, so that you always know where to get the most current functionality.

出典）https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-learn-more/


◆AAD ConnectではActive Directory以外のIDストアもサポート

現状ではまだExpress Settings（簡単設定）を行うためにはActive Directoryが存在する環境でしかAAD Connectの設定はできませんが、今後はActive Directory以外のIDストアをベースにAzure ADと同期を行うことができるようになると思われます。

Ignite 2015のセッションスライド。他のIDストアとの接続が明示されている。

ドメイン参加していないサーバにAAD ConnectをセットアップしようとするとExpress Settingsは使えないもののセットアップ・ウィザードは先に進められる。

オンプレミスのIDストアの設定にDirectory Typeというプルダウンが存在する。（現在はActive Directoryしか選択できないが）

Synchronization Managerの初期状態で管理エージェントとして以下の3種類が選択できる。

• Active Directory Domain Service
• Azure Active Directory
• Extensible Connectivity 2.0（ECMA2.0）

◆その他

ウィザードの最後にドメイン参加したWindows 10のデバイスの情報をAzure ADと同期するためのオプションについての記載もあり、今後のハイブリッドシナリオの拡張を予感させます。

今後はこのツールがAzure ADとのハイブリッドシナリオでは主役となるはずなので、他の拡張要素についても今後紹介していこうと思います。
しかし一昔前に比べてものすごく簡単にセットアップができるようになったもんです・・・。

[IdM全般]トレーニングコンテンツ色々／プロジェクトの進め方～モバイルデバイス管理～開発まで

最近のポストで2回ほど紹介したMicrosoft Virtual Academy（MVA）というオンライントレーニングコースですが、その後もアイデンティティ関連のコースを探索していたら何個か面白いものが出てきたので紹介したいと思います。

参考）これまで紹介したポスト

[IdM全般]アイデンティティ管理プロジェクトに必要なスキル（Active Directory/Azure AD編）

　http://idmlab.eidentity.jp/2015/06/idmactive-directoryazure-ad.html

[AzureAD]入門コンテンツ - クラウド時代のActive Directory次の一手シリーズ

　http://idmlab.eidentity.jp/2015/06/azuread-active-directory.html

今回紹介させて頂くコンテンツの一つ目は「ID とアクセス管理の全体像」シリーズです。

URL：http://goo.gl/GKxNMh

基本はMicrosoft Conference 2014の中のセキュリティ～ID管理系のコンテンツを集めたシリーズになっており、以下の6つのコンテンツ＋セットアップ手順書のセットになっています。

• 基本から見直すセキュリティ～標的型攻撃の実態と取り組むべきセキュリティ対策～
• Dynamic Identity Framework～クラウド時代適応のためのID管理手法～
• ハイブリッドな認証基盤で生産性を高めるために必要な基礎知識
• モバイルの企業活用を支えるデバイス統合管理ソリューション
• Azure Rights Managementによる社外ユーザーとのセキュアのコンテンツ共有の実現
• 多要素認証Deep Dive～ハイブリッド認証基盤だからこそ実現できる柔軟で高機能な多要素認証～

特に2つ目のDynamic Identity Framework（DIF）のセッションでは実際のコンサルティングプロジェクトで企業のID管理の現状分析と課題の洗い出しを行う方法論について語られているのでプロジェクトにかかわる方には参考になるかもしれません。

もちろんそのような方には、JNSAのアイデンティティ管理WGの出している「改訂版クラウド環境におけるアイデンティティ管理ガイドライン」もあわせておすすめです。（宣伝）

二つ目に紹介するMVAコンテンツはAndroid / iOSのようなモバイルデバイスを管理するためのソリューションセット「Enterprise Mobility Suite（EMS）」に関する「Taming Android and iOS with Enterprise Mobility Suite」というコンテンツです。
URL：http://goo.gl/8IOhcm

基礎的な部分からAndroid / iOSそれぞれについての具体的な仕組みや設定についてデモを交えて紹介しています。


最後は開発系コンテンツの「Customizing ASP.NET Authentication with Identity」です。
URL：http://goo.gl/t95rEu

OAuth/ソーシャルアイデンティティ連携から多要素認証まで、ASP.NET Identityでどうやって実装するのか、具体的な実装方法に関する紹介をしています。


私を含めBlogやTechnet / MSDNなどだと都度都度情報が分散してしまっているので、こういう形でまとめてあると基礎から勉強しなおすにはいいですね。

[AzureAD]アクセスルールで社外からのアクセスを制御する

※現在Public Previewとして提供されている機能なので、今後の機能変更などが発生する可能性があります。

Office365やGoogleApps等のSaaSアプリケーションのメリットはどこからでも（社内からも、社外からも）アクセスできるところにあります。
ただ、企業の情報システム部門としてはいつでも、どこでもアクセス出来るからと言って、自宅のPCやネットカフェなどの安全ではない端末からIDとパスワードだけでアクセスされるのはちょっと、、ということもあり、オンプレミスのAD FSなどと組み合わせて信頼できるネットワークからのみのアクセス出来るようにしたり、多要素認証を強制したり、と安全性を何とか確保しようと日々努力をしています。

たとえば以下のような方式です。
・社内ネットワークからしかアクセス出来ないようにする
　方法１：VPNで社内ネットワークへ参加しないとAD FSに到達できないように構成する
　方法２：AD FSのクレーム・ルールを書いてクライアントIPによって承認を制御する　
・社内ネットワーク以外からのアクセスであれば多要素認証を要求する
　方法１：AD FSの多要素認証を構成し、社外ネットワークの場合の認証ポリシーを構成する

これまで、これらの方法はいずれもAD FSが必要でしたが今回紹介するアクセスルールを使うとAzure Active Directory（Azure AD）だけで実装ができるようになるので、より手軽に実装が可能になります。

ちなみに話はそれますが、個人的にはAD FSとWeb Application Proxy（WAP）を使って社内のIdPをDMZに配置してインターネットからでも利用できるようにするくらいなら、素直にAzure ADで認証をしてしまった方が良いと考えています。セキュリティの専門家を自社に抱えていて、DMZのIdPを守る努力を日々継続的に実行できるなら話は別ですが、なかなかあることではないので、Azure ADなりOktaなりの外部のIDaaSに任せてしまった方が安全なのではないかと思います。（さらに多要素認証を使えばより強固になりますし）
この辺りはまた別の機会に書いていこうと思います。


本題に戻ります。

現在、Azure ADのアプリケーション・アクセスルールで出来ることは以下の通りです。

アプリケーション単位で、
・必ず多要素認証を要求する
・社外からのアクセスなら多要素認証を要求する
・社外からのアクセスをブロックする

ことができる。

その際、

・ルール適用対象のグループ

・ルール適用除外のグループ

を設定することができる。

では早速やってみたいと思います。

今回、テスト用アプリケーションにはGoogle Appsを利用し、多要素認証のON/OFF、ルール適用除外グループへの参加/不参加、社内/社外からのアクセスの各パターンでの挙動を確認します。

（ちなみに必ず多要素認証を要求する、というルールは単純すぎるので除外しています。単に多要素認証が要求されるだけなので）

初めに書いてしまいますが、結果は以下の表のようになります。

※External Usersというグループについてルールの適用を除外するように設定をしています。

ルール	アクセス元	所属グループ	多要素認証	結果
作業中でない場合、多要素認証が必要です - 除外：External Users	社内ネットワーク	External Users	Yes	OK
			No	OK
		Google Users	Yes	OK
			No	OK
	社外ネットワーク	External Users	Yes	OK
			No	OK
		Google Users	Yes	OK
			No	NG ※多要素認証設定が要求される
作業中でない場合、アクセスをブロック - 除外：External Users	社内ネットワーク	External Users	Yes	OK
			No	OK
		Google Users	Yes	OK
			No	OK
	社外ネットワーク	External Users	Yes	OK
			No	OK
		Google Users	Yes	NG
			No	NG

では、順番に行きます。

まずは、「作業中でない場合、多要素認証が必要です」というルールを使います。

※「作業中＝社内ネットワークからのアクセス」ととらえてください。翻訳・・・

社内ネットワークの定義は多要素認証プロバイダの管理コンソールで行います。

まずは多要素認証が設定されているユーザでアクセスします。

当然ですが、社内からでも社外からでもアプリケーションが利用できます。

次に、多要素認証が設定されていないユーザで社内ネットワークからアクセスしてみます。

こちらも当然問題ありません。

一方で同じユーザを使って社外ネットワークからアクセスしてみます。

今回は多要素認証が必要となるので、ログオン時に多要素認証のセットアップを要求されます。

ただ、この同じユーザを除外対象のグループ（External Users）へ参加させて再度アクセスすると今度は問題なくアプリケーションが利用できます。

次に、「作業中でない場合、アクセスをブロック」というルールを使います。

ルールに適合するケースは単にアクセス出来てしまうだけなので、条件に適合しない場合の挙動を確認します。

除外対象グループメンバに所属していないユーザが、社外からアクセスした場合が該当しますので試してみます。

見事にブロックされました。

エラーメッセージをよく見ると、「User account 'アカウント名' does not satisfy Access Policy」とある通り、アクセス条件を満たさなかったのでエラーが出ていることがわかります。

内勤の人など、業務上に社外からアクセスする必要がない人についてはこのようなルールを適用して安全にアプリケーションを使う、というのも良いシナリオかも知れませんね。

[IdM全般]アイデンティティ管理プロジェクトに必要なスキル（Active Directory/Azure AD編）

以下のblogにアイデンティティ・アクセス管理プロジェクトを実行する上で強みとなるスキルのリストが挙げられています。

　Killer Skills for an Identity and Access Management (IAM) Project
　http://blog.avatier.com/killer-skills-for-identity-and-access-management-project/

Red hot identity and access management skillsということで色々なスキルのリストが上がっていますが、PCが燃えあがる絵は単純に炎上プロジェクトに見えてしまいますね。

さて、書かれている内容ですが、テクニカルに寄ってはいますが、非常に基本的なスキルセットが羅列されているので新入社員を育てる上では参考になるかもしれません。
　※ちょうど、社内でどうやって技術者を育てるのか考える時期に来ている人も多いはず。
　※ちなみに私も参画しているJNSAのアイデンティティ管理WGのテーマとしても人材育成がテーマ候補として挙がっていたりします。


必要なスキルとして挙がっているのは以下の通りです。
・LDAP関連の知識
・データベースに関する知識/SQL関連の知識
・認証/認可のモデルに関する理解
・スクリプト言語


私の経験的に言うと、一般的な開発経験者にプロジェクトに入ってもらう際にまず第一にハードルになるのが実は最初に挙がっているLDAP関連、特にActive Directoryに関する知識・スキルだと思っています。
エンタープライズ領域においてアイデンティティ管理プロジェクトはやはり開発プロジェクトになることが多いので開発者をアサインするのですが、反面LDAPやActive Directoryはインフラ領域（下手するとネットワーク領域）にあるので、開発者からすると非常にハードルが高いようです。
また、インフラ系のエンジニアにとってもクラウド上のAzure ADに関してはやはり基礎から理解をしておきたい分野です。

そんな方にはマイクロソフトが用意している教育コンテンツのMVA（Microsoft Virtual Academy）、ということでActive Directory/Azure AD関係のコンテンツをまとめてみました。
一部英語のコンテンツもありますが、日本語の字幕があるのはうれしいですね。

カテゴリ	タイトル	URL
基礎	Active Directory を理解する	http://goo.gl/jHgGn4
クラウド時代の Active Directory 次の一手シリーズ	第 1 回 Active Directory の位置づけ	http://goo.gl/nAFcX0
	第 2 回 Active Directory ドメイン サービスの新しい役割	http://goo.gl/Sp6hBF
	第 3 回 Active Directory フェデレーション サービスの役割 解説編	http://goo.gl/1uEyS9
	第 4 回 Active Directory フェデレーション サービスの役割 構築編	http://goo.gl/VHgHoN
Azure Active Directory	Microsoft Azure Active Directory の概要	http://goo.gl/4UzIWO
	(MCP 70-533 対応) Microsoft Azure インフラの実装 ～ Part 2 Azure Active Directory の実装編	http://goo.gl/mykkL0
	Azure Multi-Factor Authentication	http://goo.gl/Yk7Ne5
Office 365	Office 365 Identity Management	http://goo.gl/8bfJfl

[Windows10]K-Byte Fingerprint Security ReaderでWindows Hello

先日のポストでIntel RealSense F200でWindows Hello（顔認証）を試して玉砕した話は書きましたが、今度は指紋認証デバイスを試してみます。

　前回のポスト：[Windows10]Intel RealSense F200でWindows Hello
　http://idmlab.eidentity.jp/2015/06/windows10intel-realsense-f200windows.html


今回使ったのは、K-ByteのFingerprint Security Readerです。
日本のAmazonでは売っていないので、USのAmazon.comで探すとたったの$12で購入することができます。（USからの送料を入れると$33ちょっとで購入できます。Express Shippingを使ったので5日くらいで届きました）

こちらから購入できます。
http://amzn.to/1S7fFYr

特にドライバをインストールする必要もなく、生体認証デバイスとして認識されます。

デバイスを正しく認識できれば、アカウント設定のサインインオプションのWindows Helloのところに指紋認証のセットアップメニューが出てきます。

さっそくセットアップをしてみます。

Windowsのご挨拶。。。。なかなか素敵な翻訳です。

「開始する」をクリックするとPINの入力を求められます。

次に指紋の登録を求められるので、数回スキャンをします。

何度かスキャンします。

うまく行くと登録が完了しますので、さっそくログアウトしてみます。

ログイン画面にサインインオプションとして指紋が追加されます。
※画面ショット取得の都合上、ここから英語OSの画面を掲載しています。
　（単純にログイン画面の画面ショットを撮るためにVM上に構成したのですが、手元のVMが英語版しかなかったので。。。設定は物理マシン上の日本語OSで画面ショットを取得しています）

ここで指紋をスワイプし、うまく認識されるとログインできます。

ちなみに、うまく認識できないと以下のようなエラーが出ます。

単純に指紋認証だとWindows8.1のころとそれほど変化がないので、個人的にはやはり早く顔認証を使ってみたいなぁ、、と思います。


追記）
　尚、現状だとMicrosoftアカウントもしくはローカルアカウントだとWindows Helloが使えますが、AAD JoinしたAzureAD上のアカウントでログインするとBioEnrollmentHost.exeがクラッシュしてWindows Helloのセットアップができません。
（バグなのか、環境が悪いのかはわかりませんが）

[Google/ACS]6/1を迎えてAzureACSのGoogle IDプロバイダーはどうなった

2015/04/20をもってGoogleのOpenID 2.0のサポートが終了し、マイクロソフトもAzure ACS（アクセス制御サービス）のGoogle IDプロバイダー設定を6/1までに変更するようにアナウンスを出していました。

関連ポスト）
　GoogleのOpenID 2.0サポート終了による影響いろいろ（Azure ACS編）
　http://idmlab.eidentity.jp/2015/03/googleopenid-20azure-acs.html

　[Google]4/20を迎えてAPIはどうなった？
　http://idmlab.eidentity.jp/2015/04/google420api.html


と、いうことで6月を超えたのでACSがどうなったのかを確認してみました。
結果、まだOpenID 2.0が動いています。結構しぶといです。
（人によって動いていない、という話もあるようなので環境に依存するのかもしれません）

これまで通りの動きです。
１．アプリケーションの認証の設定を行います。

２．実行するとレルムディスカバリ画面がでます。

３．Googleアカウントでログインします。

４．認可をおこないます。

５．アプリケーションからGoogleの属性が取得できています。

このように中々しぶとい状況ですが、MSDNには以下のアナウンスが出ています。
https://msdn.microsoft.com/ja-jp/library/azure/dn927169.aspx

・2015 年 6 月 1 日 - ACS 名前空間は Google の OpenID 2.0 実装の使用を停止します。この日までに、ACS 名前空間の移行を完了して、Google OpenID Connect を使用する必要があります。この日までは、移行中に問題が発生しても、OpenID 2.0 にロールバックできます。
ほとんどの場合、アプリケーション コードの変更は必要ありません。アプリケーションに関連付けられているルール グループに ID プロバイダーとしての Google に対して "すべての要求をパススルーする" というルールが存在する場合は、コードの変更が必要になる場合があります。これは、移行によって Google からの新しい要求の種類 (サブジェクト) が ACS で利用可能になることから、アプリケーションが新しい要求の種類の存在を適切に処理できるようにコードを変更する必要が生じる場合があるためです。移行を正常に完了させるうえで、アプリケーションで新しい要求の種類を処理する必要はありません。
・2017 年 1 月 1 日 - Google の OpenID 2.0 と OpenID Connect の実装では、Google ユーザーを一意に識別するのに、異なる識別子を使用します。ACS 名前空間の移行後は、現在の OpenID 2.0 識別子と新しい OpenID Connect 識別子の両方をアプリケーションで使用できるようになります。この日までにバックエンド システムでユーザーの識別子を OpenID Connect 識別子に切り替え、以降は OpenID Connect 識別子のみを使用する必要があります。これには、アプリケーション コードの変更が必要です。

ACS側の移行が終わっても次は2017/01/01までに従来のOpenID 2.0で使っていた識別子（nameidentifier）ではなく、OpenID Connectの識別子（subject）を使うようにアプリケーションの改修を行う必要があるようです。
ACS側でのクレームのマッピングを修正する形にしたほうが柔軟な気もしますので、私ならACSのクレームマッピング（規則グループ）を変えますが。。
※この図のnameidentifierとsubjectのマッピングを合わせてあげる形にします。既存アプリケーションはnameidentifier属性を見ているはずなので、OpenID Connect対応した際にGoogleから取得できるようになるsubject属性を出力側のnameidentifier属性にマッピングしてあげればアプリケーションを改修する必要はありません。

まだまだ余裕はありますが、こちらの改修も早めに実施しておいたほうがよさそうですね。

※使えなくなる瞬間どうなるのかを確認したいので、あえてACSの設定を移行せずに残してあるのですが、中々使えなくならないので、今後も引き続きウォッチしていきたいと思います。

[AzureAD]入門コンテンツ - クラウド時代のActive Directory次の一手シリーズ

今でこそ一般名詞になってしまった「Active Directory」ですが、Windows 2000 Serverが出てきた当時は、いったい何がどうアクティブなのかさっぱり・・・でした。

（私は当時ActiveXのコンポーネント開発なんかをやっていたので、「最近のマイクロソフト的なブームはアクティブなのか～」と思っておりました。当時はMicrosoft DNAとか色々と有りましたねぇ）

と、まぁ昔話をしても仕方がないのですが、Active Directoryも進化・多様化が進み、AD LDSやらAD RMSやらAD CSやらAD FS、ついにはAzure ADなんていうものまで出てきて、いわゆるNTドメインとはかけ離れたものになってきています。

どうやらここら辺でActive Directoryシリーズについてのおさらいと、今後Active Directoryがどうなっていくのか？について簡単におさらいをしておく必要がありそうです。

そんな方には「Microsoft Virtual Academy（通称MVA）」です。

色々なオンライン・トレーニングコンテンツが無償で公開されており、ユーザ登録をしなくても参照が可能ですし、ユーザ登録をすれば学習の進捗に合わせてポイントをためたり、コンテンツのダウンロードができたりします。

今回はMS安納さんが公開している「クラウド時代のActive Directory次の一手」シリーズを紹介します。

現在第4回まで公開されており、概要からAD FSの構築の部分まで動画で確認することができます。

クラウド時代の Active Directory 次の一手シリーズ

• 第 1 回 Active Directory の位置づけ
• 第 2 回 Active Directory ドメイン サービスの新しい役割
• 第 3 回 Active Directory フェデレーション サービスの役割 解説編
• 第 4 回 Active Directory フェデレーション サービスの役割 構築編

こんな感じで、スライドを使ったプレゼン動画が参照できます。

1回あたり30分程度なので、それほど時間も取られませんし、簡単に参照もできるのでこの機会に基本的なところからおさらいをしてみると良いかも知れませんね。

[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の対応が待ち遠しいです。