第4回 Windows 10によるAzure Active Directory活用の最大化：企業のID管理／シングルサインオンの新しい選択肢「IDaaS」の活用（2/3 ページ）
オンプレミスのActive Directory（AD）はなくなるの？ 最新のWindows 10、そして間もなく登場のWindows Server 2016と連携することで、Azure ADがどのように役立つのか、どう活用すべきなのか明らかにする。
Azure AD参加の裏側：「Microsoft Passport」と「Windows Hello」
ここまでの説明で、Azure ADへ参加することにより、デバイス−アプリケーション間のシングルサインオンがクラウドサービスにおいても実現でき、Microsoft Intuneを使うことである程度のデバイス管理ができることが分かる。
次に、Azure AD参加によるデバイス−アプリケーション間のシングルサインオンを裏側で支えている「Microsoft Passport」について、オンプレミスのActive Directoryへの参加と統合Windows認証と対比しながら解説する。
結論から述べると、いかにしてパスワードなどの認証情報を拡散させずに利便性を向上するか、が焦点となっている。実はデバイス−アプリケーション間のシングルサインオンを実現するための基本的な考え方はオンプレミスのActive Directory参加でもAzure AD参加でも大きな違いはない。異なるのは利用しているプロトコル（Kerberos対HTTPベース）と、サインイン時に初期チケットを取得する際のユーザー認証の考え方の2点である。
●デバイス−アプリケーション間のシングルサインオンの仕組み
まずは考え方を理解するために、これまで統合Windows認証を支えてきたKerberosによるデバイス−アプリケーション間のシングルサインオンの仕組みを整理しておく。
最初に、統合Windows認証の処理の流れを解説する。詳細は省くが、PCへのサインインからリソースへのアクセスは以下のようなステップとなっている。
オンプレミスActive Directoryでの統合Windows認証の処理
いったんサインインすると、パスワード情報を何度も入力したり、リソース側にユーザーのパスワードを保存したりすることなく、シングルサインオンを実現できるようになっている。
（1）PCへサインインする。
（2）ドメインコントローラー（KDC：Key Distribution Center）よりTGT（Ticket-Granting Ticket）を取得する。
（3）TGTをドメインコントローラーへ提示する。
（4）ドメインコントローラーよりST（Service Ticket）を取得する。
（5）STをリソースに提示し、利用を開始する。
これに対して、Azure AD参加時のシングルサインオンについては、TGTの代わりに「PRT（Primary Refresh Token）」、STの代わりに「Access Token」を使用する。この仕組みを、後述のデバイス登録の仕組みと合わせて「Microsoft Passport」と呼ぶ。
Azure ADでの認証の処理
（1）デバイスに保持されている秘密鍵で署名した認証リクエストをAzure ADへ送信する。（セキュリティチップである「TPM」が搭載されているPCなら、TPM上に秘密鍵は保持されている）。
（2）Azure ADに登録されている公開鍵（リクエスト署名に使われた秘密鍵とペア）を使って、署名を検証する。
（3）Azure ADよりPRT（Primary Refresh Token）を取得する。
（4）取得したPRTをAzure ADへ提示する。
（5）Azure ADよりAccess Tokenを取得する。
（6）Access Tokenをリソースへ提示し、利用を開始する。
＊内部的にはPRTやAccess Tokenの取り扱いはWeb Account Managerというコンポーネントが担当しており、各種トークンのやりとりをする先の認証プロバイダーのプラグイン（Cloud Authentication Provider Plugin）を複数登録できるようになっている。デフォルトではAzure ADと接続するためのプラグインが登録されている一方で、API仕様が公開されているため、今後サードパーティーのプラグインが開発されれば、Azure AD以外の認証プロバイダーでもデバイスの登録〜認証ができるようなる。
このように従来の統合Windows認証でもMicrosoft Passportでも、サインイン時に取得した初期チケット（TGT／PRT）をリソースへアクセスするための個別チケット（ST／AT）へ交換して利用するという点において、考え方に大きな違いはないことが分かる。
●デバイス登録の仕組み
同様に、ドメインへの参加しているデバイスの識別についても、両者は非常に類似した仕組みになっている。
オンプレミスのActive Directory参加ではコンピューターをドメイン上に登録する際、コンピューターアカウントとパスワードの生成が行われる。以後、生成されたアカウントとパスワードでコンピューターを認証することにより、信頼済みのコンピューターでのみユーザーがサインインできるようになっている。
それに対してAzure AD参加では、鍵ペアを利用したコンピューター認証を行っている。Azure ADへの参加の際、PC上で鍵ペアを生成し、秘密鍵をデバイス上のTPM上へ、公開鍵をAzure ADのDRS（Device Registration Service）へそれぞれ登録する。以後は、先に述べた通り、ログオンする際はPC上の秘密鍵による署名をAzure AD側の公開鍵で検証することで、サインイン〜PRTの発行が行われることとなる。
Azure ADでのデバイス登録の処理
Azure ADへの参加時には、鍵ペアを生成し、秘密鍵をTPM上へ、公開鍵をAzure AD DRS（Device Registration Service）へ登録する。
●Microsoft Passportにおけるユーザー認証の役割
最後に、一番の変化点となっているデバイスへのサインイン時のユーザー認証の役割について解説する。
先に述べたようにAzure AD参加済みデバイスへログオンする際は、あくまでTPM上の秘密鍵によって署名されたリクエストをAzure AD側がペアとなる公開鍵で検証することで完結している。そのため、ユーザー自身の認証がAzure AD側で行われているわけではない。この点で、従来のActive DirectoryでのKerberos認証のように、ユーザーIDとパスワードを暗号化してドメインコントローラーへ送付する仕組みとは大きく異なる。
Microsoft Passportを利用したログオンプロセスでは、ユーザー認証はあくまでTPM上の秘密鍵を取り出す目的で行われ、デバイス上で完結する。そのため、ユーザーは新規デバイスでサインインする都度、そのコンピューターでのみ通用するPINコードの登録を行う必要がある。
Azure ADでのユーザー認証の処理
ログオン時のユーザー認証は、あくまでも秘密鍵へアクセスするために行われる（この時点でAzure ADとの認証はまだ始まっていない）。
（1）TPMから秘密鍵を取り出すための手段として、PINや顔・指紋といった生体情報を利用できる。
（2）取り出した秘密鍵で、Azure ADへの認証要求に署名する。
（3）認証要求を受け取ったAzure ADは、その署名を公開鍵で検証する。
このように、TPM上から秘密鍵を取り出すための手段としてのみユーザー認証が行われるため、認証手段についてはデバイスの特徴に合わせてさまざまな方法を選択できるようになっている。このための手段の一つが「Windows Hello」と呼ばれる生体認証のフレームワークである。
Windows Helloを使った顔認証サインイン
これは顔認証をサポートしたWebカメラを接続したWindows 10マシンの例。
（1）赤外線に対応したWebカメラでユーザーの顔を撮影して認証し、サインインさせようとしている。
このように、鍵ペアを使ったデバイス認証の仕組みと、TPMから秘密鍵を取り出すためにデバイス側で行われるユーザー認証を組み合わせることにより、ネットワーク上を流れるユーザー自身の認証情報（パスワード）は極小化され、全体としてセキュリティが向上されている。これもIDaaSとデバイスの連携が強化されたことにより得られるメリットの一つである。
ここまでの解説してきた相違点をまとめると、以下の表の通りとなる。
| フェーズ | Azure AD参加 | オンプレミスAD参加 | ||
| デバイス−アプリケーション間のシングルサインオン | 認証後の元チケット | PRT（Primary Refresh Token） | TGT（Ticket Granting Ticket） | |
| リソースアクセス用チケット | Access Token | ST（Service Ticket） | ||
| デバイス登録 | 認証情報の生成と登録 | 鍵ペアの生成と登録 | コンピューターアカウントとパスワードの生成と登録 | |
| サインイン | ユーザー認証 | デバイス内で実施（ネットワークを経由しない） | ドメインコントローラーで実施（ネットワーク経由） | |
| コンピューターの認証 | 秘密鍵による署名を公開鍵で検証 | コンピューターアカウントのパスワードによる認証 | ||
| オンプレミスAD参加とAzure AD参加の技術的な比較 | ||||
【コラム】Microsoft Passportによる新たなハイブリッド構成
従来のAzure ADとAD FSの組み合わせによるハイブリッド構成では、社内でドメインに参加したPCでAzure ADと連携したアプリケーションにアクセスする際、IDだけは入力する必要があった（IDを入力するとAzure ADによりAD FSへリダイレクトされ、統合Windows認証によりシングルサインオンされる）。
Azure ADとAD FSで連携していてもIDの入力だけは求められる
これはMicrosoft Azureのサインイン画面。
（1）従来のハイブリッド構成ではID（メールアドレス）だけは入力する必要があった。
しかし、「Azure AD Connect」を使うと、ドメインに登録されたWindows 10デバイスの情報をAzure ADへ同期することでMicrosoft Passportに必要な公開鍵の情報がAzure ADに登録される。そのため、再度IDを入力することなくアプリケーションを利用することが可能になっている。
Azure AD Connectによるデバイス情報の同期
オンプレミスActive Directory上に登録されたデバイス情報がAzure AD ConnectによりAzure ADへ同期され、Microsoft Passportが使えるようになる。
Windows 10とAzure ADを使ったデバイスとアプリケーションの間のシングルサインオン、およびWindows Helloについては、筆者が制作した動画やブログ記事で解説しているので参考にしていただきたい。
■Channel 9で公開している筆者の解説ビデオ
- Surface Pro 4でWindows Hello（Channel 9）
■筆者ブログ「IdM実験室」の関連記事
■SlideShareで公開している筆者のスライド
Copyright© Digital Advantage Corp. All Rights Reserved.