山市良の「企業ユーザーはここに注目しよう！Windows 8.1の新機能」 第2回

Windows 8.1やiOS、Androidデバイスから社内リソースへのアクセスを容易に

Win 8.1のBYOD機能「社内参加（Workplace Join）」を使う

実際のところ「社内参加」で何が変わるのか、何ができるのか

　ここまで、まずデバイス側での社内参加の手順を紹介したが、Windows Server 2012 R2のADドメインを展開すればすぐに社内参加が利用できるようになるわけではない。社内参加のデバイス登録とデバイス認証を可能にするのは、AD FSおよびAD FSに追加された「Device Registration Service（DRS）」である。

　DRSは社内参加を要求したデバイスに対して、ADドメイン認証に基づいてデバイス認証のための証明書を提供する。しかし、これだけではまだ社内参加デバイスが企業内のリソースにアクセスできる状態にはない。

　AD FSは、WS-FederationやSAMLによる「クレームベース認証」に対応したWebサイトやアプリケーションに対して、プライマリ認証方法として「デバイス認証」のオプションを提供する。つまり、社内参加したデバイスがデバイス認証でアクセスできるのは、AD FSに登録されたクレームベース認証対応のアプリケーションだけということになる。たとえば企業内の「SharePoint」サイトやクラウドサービスの「Office 365」、「Windows Identity Foundation（WIF）」を用いて独自開発したアプリケーションへのSSOにデバイス認証を利用できるのであり、社内参加をしたからといって企業内の共有フォルダーに自由にアクセスできたりするわけではないのだ。

※筆者追記：Windows Server 2012 R2の新機能である「Webアプリケーションプロキシ（Web Application Proxy）」を間に置くことで、「作業フォルダー（Work Folders、連載第3回で紹介）」やリモートデスクトップWebアクセスなど、クレーム非対応のWebアプリケーションに対してもAD FSによるデバイス認証を事前認証として実装できるようだ。（2013年9月17日）

社内参加を利用するには、AD FSのDevice Registration Service（DRS）をセットアップする必要がある

　以下のページで公開されている社内参加のワークスルーガイドでは、DRSの展開手順や、デバイス認証を確認するためのサンプルアプリケーションとその公開方法が説明されている。サンプルアプリケーションは「Windows Identity Foundation SDK」（http://www.microsoft.com/en-us/download/details.aspx?id=4451）に含まれるもので、クレームベース認証に使用されたセキュリティトークンの内容を表示するという簡単なものだ。社内参加前と社内参加後のアプリケーションへのアクセスの違いと、セキュリティトークンの内容を比較することで、デバイス認証によるSSOを確認することが可能だ。

■Get Started with Workplace Join with a Windows Device: Walkthrough Guide
http://technet.microsoft.com/en-us/library/dn280938.aspx

■Get Started with Workplace Join with an iOS Device: Walkthrough Guide
http://technet.microsoft.com/en-us/library/dn280933.aspx

（左）社内参加設定をしていない未登録のデバイスからサンプルアプリケーションにアクセスすると、アプリケーションにアクセスするたびにWindows認証またはフォーム認証による資格情報の入力が求められる。（右）セキュリティトークンにデバイスに関する情報は含まれていない

（左）社内参加設定をした登録済みデバイスからサンプルアプリケーションにアクセスすると、初回に資格情報の入力が求められるが、2回目以降は認証を求められずにアクセスできる。（右）セキュリティトークンには、デバイスに関する情報が含まれる

　このサンプルアプリケーションが示すように、アプリケーションを提供する側はアクセス元のデバイスの登録状況（登録済みか未登録か）に基づいて、アプリケーションへのアクセスを許可することができる。

　Windows Server 2012 R2のAD FSは「多要素認証（MFA：Multi-Factor Authentication）」に標準で対応しており、デバイスの登録状況やアクセス元の場所を条件として、追加の認証を要求することもできる。これを利用すれば、アプリケーション側の認証メカニズムでデバイスの登録状況を判断しなくても、未登録デバイスからのアクセスを簡単にブロックできる。未登録デバイスからのアクセスを許可しないのなら、追加の認証を実装する必要もない。なお、ADドメインメンバーのPCやデバイスは、DRSにとっては未登録デバイスという扱いだが、ドメインメンバーであっても社内参加設定はできる。

（左）Windows Server 2012 R2のAD FSは、多要素認証の認証方法として証明書認証（クライアント証明書やスマートカード認証）を標準でサポートしている。（右）社内参加設定をしていない未登録デバイスに対して、アプリケーションに実装していない証明書認証を追加で求めることで、未登録デバイスからのアクセスをブロックできる

クレームベース認証は難解だがデバイス／クラウド時代には避けて通れない

　「社内参加」機能を活用するには、クレームベース認証の理解とアプリケーションへの実装が必要になる。しかしクレームベース認証は、その概念や仕組み、使われる用語が難解である。特に日本においては「クレーム」という言葉が「苦情」という、この英単語（claim＝要求、請求）には元々ない意味で使われることが多いからややこしい。もちろん、クレームベース認証には「苦情」なんてまったく関係していない。

　ここでクレームベース認証の説明を試みようとは思わないが、今回紹介した社内参加だけでなく、企業におけるクラウドサービスの利用においてもキーとなる要素技術である。もしこれまで避けてきたのであれば、いまこそ重い腰を上げるときだろう。

＊　　＊　　＊

　次回も引き続き、Windows 8.1とWindows Server 2012 R2のBYOD対応機能について見ていく。次回取り上げるのは「作業フォルダー（Work Folders）」機能だ。

筆者紹介：山市良（山内和朗）

　

Windows Server系の書籍、記事、技術文書を得意とするITテクニカルライター。2008年からMicrosoft MVP for Virtual Machineを受賞（Oct 2008 - Sep 2013）。主な著書に「Windows Server 2012テクノロジ入門」（日経BP社、2012年）、「Windows Server仮想化テクノロジ入門」（日経BP社、2011年）、「Windows Server 2008 R2テクノロジ入門」（日経BP社、2009年）。ブログ http://yamanxworld.blogspot.jp/