こんにちは、富士榮です。
それではどうぞ。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
Windows 10デバイスを利用する際の利点の一つは、Azure ADに登録されたWindows 10のデバイスは、Windows HelloとMicrosoft Passport for Workにより実現する利便性とセキュリティです。このポストでは、Azure ADと連携するMicrosoft Passport for Workのテクノロジについて、およびそれがどのようにデバイスと強固な認証と関連するのかを掘り下げていきます。
パーソナルデバイスに関する簡単なメモ
2015年11月の更新プログラムを適用したWindowsのパーソナルデバイスの場合、Microsoft Passport for Workは、ユーザに関連づけられたジェスチャー（詳細については今後のポストで紹介します）によるクレデンシャルのアンロックによる従来のアプリケーション（VPNなど）のための証明書の保護については限定的です。 これらの証明書は一般的にモバイルデバイス管理（MDM）システムによって配備されます。
Microsoft Passport for Workは、MDMがAzure ADに対して自動登録設定が行われていない限り、職場または学校のアカウントの追加を行っても表示されてきません。この場合、このデバイスを利用しているユーザーは、Microsoft Passport for Workを使用して、Azure ADで認証されません。これは将来のWindowsのアップデートにより、サポートされる予定です。
一方、（個人的なデバイスを含む）Windows 10のデバイスが持つクレデンシャルは、Azure AD参加もしくはドメイン参加したデバイスへのリモート認証するために利用できます。詳細については今後のポスト、Microsoft Passport for Work 2Go：携帯電話を利用してWindowsへの認証を行うをご覧ください。
パスワードの現状
今日、パスワードには問題があります。それらは複製しやすく簡単に盗むことが出来ます。それら実装における問題は、パスワードを安全ではないものとし、ユーザーは利便性とセキュリティのバランスをとるのに苦労しています。しばしばユーザーはセキュリティ要件が求められた際、簡単に利用するための「回避策」を見つけてしまいます。（例えば、複雑なパスワードが求められる場合、それを保護されていない場所に書いてしまうこともあります）
Microsoft Passport for Workは、ユーザーのジェスチャー（PINもしくは指紋や顔認識などの生体ジェスチャー、すなわちWindows Hello）によって保護された、デバイスに強固に紐づけられたユーザーの資格情報を使用してユーザーのパスワードを置き換えます。
Microsoft Passport for Workの資格情報
資格情報は、デバイスのトラステッドプラットフォームモジュール（TPM）にセキュアに保存された秘密鍵、およびAzure AD上に安全に登録された対応した公開鍵の構成される非対称鍵（秘密鍵と公開鍵のペア）です。 TPMが存在しない場合、キーはソフトウェア的に生成され、暗号化されて保存されています。
秘密鍵は、安全な場所を出ることはなく（TPMが利用可能な場合）、Azure ADまたはADに知られることも、ネットワークを流れることもありません。 それは、"Hello"を使って暗号化・保護され、ユーザーが知っていること（PIN）もしくはユーザーが誰であるか（バイオメトリクス）によってのみアクセスが可能です。”Hello”はジェスチャー、デバイスとユーザー毎に固有な認証器なのです。
公開鍵は、デバイスとユーザーの両方の認証が完了した後にAzure ADに安全に登録されます。ユーザーは第2の要素を提供することで、強固に認証される必要があります。Microsoft PassportはAzure ADで認証する際、強力な資格情報と見なされるため、これは重要なことです。資格情報が多要素認証（MFA）ポリシーを満たし、この資格情報で取得されたトークンは、対応する関連属性を含みます。
資格情報がプロビジョニングされると、それはAzure ADでの認証のために使用されます。
Microsoft Passport for Workの資格情報のプロビジョニング
すべては、デバイスがAzure ADに登録されるところから始まります。デバイスはMicrosoft Passport for Workの資格情報を取得する前に、Azure ADへ参加、もしくはドメインへ参加（することによるAzure ADへ自動登録 ）、職場または学校のアカウントを追加している必要があります。
Azure ADへ参加もしくはドメイン参加したデバイスの登録が完了した後、次回にユーザーがWindowsへサインインする際、Microsoft Passport for Workのプロビジョニング画面が表示されます。Azure ADへの公開鍵の登録は、Azure Device Registration Service（Azure DRS）によって行われます。
これはシステム内の特定のWinRT APIへアクセス可能なホストである、Cloud eXperience Host（CXH）内にレンダリングされるWebドリブンの画面です。これはAzure AD参加の際に使用されているもののと同じホストです。
以下の条件に該当する場合 、Windowsにユーザーがサインインした後に起動されます：
- Microsoft Password for Workのポリシーがプロビジョニングされている。これは次の条件のいずれかを意味します：
- デバイスがAzure ADに参加しており、Microsoft Passport for Workのポリシーが無効になっていない （ポリシーが存在しない場合のデフォルトの動作では、資格情報をプロビジョニングします）。
- デバイスがドメイン参加しておりポリシーが有効になっている（ポリシーが存在しない場合のデフォルトの動作では、資格情報のプロビジョニングを行いません）。これは、ドメイン参加したデバイスが資格情報を使用してドメインコントローラ（DC）で認証できるようにオンプレミスのインフラストラクチャに必要な準備を行うためです。必要な設定が行われた後、組織はポリシーを有効にすることができます。記事の後半でオンプレミスADの認証のサポートに関するいくつかの考慮事項について言及します。
- 現在のセッションがリモートセッションでないこと。これはMicrosoft Passport for Workのプロビジョニングが仮想マシン（VM）上で発生しないことを意味しているわけではありません。しかし、ユーザーがリモートデスクトップサービスセッション（RDS）経由でVMまたは物理デバイスに接続している場合、プロビジョニング画面は表示されません（これはHyper-Vの拡張セッションモードでの接続を含みますので、検証環境で試す場合はHyper-Vホスト上で行う必要があります）。
上記の条件が満たされると、プロビジョニング画面が表示されます。これは次の場所でホストされています：
https://account.live.com/aadngc
次のページが表示されます。
ユーザーが「PINを作成」ボタンをクリックするとdsreg.dllのWinRTのAPIの部分が呼び出されます。この登録APIは、次の2つの操作を実行します：1）Azure DRSでトークンを取得するために現在のユーザーを認証する、2）鍵ペアを生成し、（1）で得られたトークンを使用してAzure DRSへ公開鍵を登録する。
(1) Azure DRSでのユーザー認証
まず初めに登録APIは、次に生成される公開鍵をAzure ADに登録するためのアクセストークンを取得します。このトークンは、Azure DRSが対応するユーザーに公開鍵を登録し、対応するデバイスオブジェクトと関連づけるために利用されます。トークンを取得するため、登録APIはWebアカウント・マネージャのAPIを使用します。
Windows.Security.Authentication.Web.Core.RequestTokenForWindowAsync
このAPIは、Azure ADプラグインの対応する実装を呼び出します。ウェブアカウントマネージャーとAzure ADプラグインの詳細については今後の記事、Windows 10においてSSOはどのように動作するのかを参照してください。
いくつかの条件に応じてユーザーにはMFAが要求されます。
- ドメイン参加デバイス上のユーザーはMFAが要求されます。これはユーザー名とパスワードの資格情報を使用しています。Windows 10の2015年11月の更新では物理または仮想スマートカードを使用してWindowsにログインしている場合、Microsoft Passport for Workはサポートされませんので注意してください。これはWindowsの将来のアップデートで対応されます。
- Azure AD参加デバイス上のユーザーは、そのユーザーが最初にこのデバイスをAzure ADへ参加させたユーザで、デバイス参加時に多要素認証されている場合、MFAを要求されません（デバイスオブジェクトの属性「RegisteredOwners」にこのユーザーが設定されます）。Azure ADはデバイス登録時に多要素認証が行われた場合、そのデバイスを認証の第2要素として扱います。この動作はこの記事が書かれた時点のサービスの動作であることに注意してください。私たちは、登録されたデバイスを多要素としてに扱うことに関する複数のフィードバックを受けとっています。将来的には、組織が制御することができる設項目定の中で設定できるようにする予定です。
- Azure AD参加デバイス上のユーザーで、デバイスをAzure ADへ参加させたユーザーではない場合はMFAが要求されます。
フェデレーションを行っている組織の場合、MFAはAzure ADもしくは組織内のSTS（例えばAD FS）から要求することが出来ます。
ユーザーが認証され、APIがトークンを取得した後、Microsoft Passport for Workの鍵の生成と登録プロセスへ進みます。
(2) Microsoft Passport for Workの鍵の生成とAzure ADへの登録
登録APIは、鍵を生成し利用可能な場合はAttestationデータを取得するには、Microsoft Passportの暗号API（ncrypt.dllの一部）に依存しています。現状のクライアントとサービスの実装ではまだAttestationの検証をサポートしていませんのでご注意ください。サービスおよび/またはWindowsの将来のアップデートでこの機能が有効になります。
一般的に鍵はこの瞬間に作成されるのではなく、事前に生成された鍵のプールから取得されます。複数の鍵の事前生成は、デバイスの起動時にバックグラウンドで実行されます。RSA 2048ビットの鍵ペアの生成はTPMに依存し、生成するのに少し時間がかかります。
鍵ペアが得られた後、PIN設定のためのUIが表示され、ユーザはPINを要求されます。論理コンテナが作成され、秘密鍵はその中に配置されます：
コンテナは、ジェスチャに関連付けられている保護鍵で保護されている鍵情報の論理的なグループです。この場合、PINはこのとき得られた保護鍵に関連付けられます。この鍵は、取得したMicrosoft Passport for Workの秘密鍵を安全にラップします。PINのジェスチャーは、論理コンテナを開き秘密鍵へアクセスするためのものです。
鍵のAttestationについて
前述したように、Attestationの検証はまだ実装されていませんが、ここでAttestationの生成の背後にあるメカニズムのいくつかの詳細を解説します。対応する公開鍵と共に、利用可能な場合は関連するAttestationデータも、暗号化APIを使用して取得されます。AttestationデータはAttestation Identity Key（AIK）証明書とユーザーと生成されたMicrosoft Passport for Workキーに関する情報を保持しているBlobで構成されています。Blobは、TPMがプラットフォームの認証を提供することを可能にする特別な目的のRSA鍵であるAIKによって署名されています。Endorsement Key（EK）および（製造者からの）証明書と併せてAIKは、TPM製造者と信頼のチェーンを持つAIK証明書を生成するために、Azure証明書サービスへ送信されます。この信頼チェーンは、サービスがキー登録時に検証するためのものです。
登録APIは、Azure DRSのアクセストークンと鍵情報を取得し、Azure DRSの次のエンドポイントにPOSTします。
POST http://enterpriseregistration.windows.net/EnrollmentService/Key
Azure DRSはディレクトリ内のユーザーオブジェクトを検索し、特定のマルチバリュー属性に鍵情報を追加します。 鍵情報にはデバイスIDへの参照が含まれています（ユーザとデバイスIDの両方がトークンから取得されます）。 ユーザオブジェクトは、Microsoft Passport for Workの資格情報をプロビジョニングしたそれぞれのデバイスに対して1つのキーを持ちます。
Azureの管理ポータル内のユーザーのデバイスのUIについて
もう一つ興味深い点を。Azureの管理ポータル内のUIにはユーザーが自身が（Azure AD参加もしくは職場または学校のアカウントを追加によって）登録したデバイスの情報が表示されます。ドメイン参加したWindows 10デバイスは、Azure ADへのデバイス登録プロセスにユーザーが参加しないため、管理ポータルのUIには表示されません。例外として、ユーザーがMicrosoft Passport for Workの資格情報をプロビジョニングすると管理UIのユーザーのデバイスの下にドメイン参加したデバイスが表示されます。
Microsoft Passport for Workの資格情報を使用した認証
最終的に資格情報がプロビジョニングされた後、その資格情報をAzure ADでの認証時、およびオンプレミスのADでのWindowsへのサインイン時に利用することが出来ます。どのようにこれが行われるのかの詳細については将来の記事、Windows 10においてSSOはどのように動作するのかを参照してください。
オンプレミスのADへの認証
新しいDCを展開する代わりに、Microsoft Passport for Workで使用されるログオン証明書を展開することもできます。 この場合、下位バージョンのDCでは認証に証明書（今日と同様に仮想スマートカード）を利用し、ユーザーはWindows Helloのメリットを享受できます。この場合においてもAzure ADは認証に鍵を使用していきますのでご注意ください。
オンプレミスのADへの認証を有効にする場合の展開の要件の詳細についてはTechnetのMicrosoft Passport guideの展開の 要件セクションを参照してください。また、より多くのリソースを参照するには関連するTechNetドキュメント（ここ）を参照してください。
最後に、ここまで読んでいただき、これらの機能に興味を持っていただいたことに感謝します。質問やコメントがあればお聞かせください。
ではまた次回。
Jairo Cadena（Twitter：@JairoC_AzureAD）
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
他にもJairoさんの記事には興味深いものが多数あるので、また翻訳をしてみなさんに公開していきたいと思います。
投稿
