[Office Preview]Outlook等の多要素認証サポート

発表されてからずっとクローズド・ベータという形となっており、公には音沙汰がなかったOffice2013の多要素認証サポートですが、Office2016 Public Previewという形で出てきました。

　Office Blog

　　Announcing the Office 2016 IT Pro and Developer Preview

　　http://blogs.office.com/2015/03/16/announcing-the-office-2016-it-pro-and-developer-preview/

発表によると、DLP（Data Loss Prevension/情報漏えい防止）やIRM（Information Rights Management）に加えて、OutlookのADALサポートが発表されています。

Multi-factor authentication. With this release of the Outlook client, we’ll support multi-factor authentication through integration with the Active Directory Authentication Library (ADAL)

これまでブラウザベースでのOffice365利用では多要素認証などによるクライアントデバイス制御を実装出来ましたが、ws-trustを使うMSOnline Signin Assistant経由のリッチクライアント（OutlookやLyncのCommunicator）では細かい制御ができませんでした。

今回、ADALベースとなることで、OAuth2.0 JWTベースとなるはずなので、Office365を使う場合に以下のメリットが得られます。

• AD FSでIdPを構成していてOutlook/Communicatorを使う場合はWAP/AD FS Proxyを使ってws-trustのエンドポイントをインターネットに公開する必要がありましたが、パッシブ・プロトコルへの変更となるため、社内利用に限ればWAP/AD FS Proxyが不要
• 同じ理由で.localドメインでの構成が容易に
• 同じ理由で公開用の証明書が不要に（社内だけで使うオレオレ証明書でOK）
• サードパーティIdPを構成してOutlook/Communicatorを使う場合、ws-trustやSAML ECPに対応したIdPが必要でしたが、単純にws-federation/SAML WebSSO Profileで対応可能なので相当ハードルが下がる

是非Connectサイトから申し込んで、試してみましょう。

参考）以前のPOST

　Office2013 Windowsクライアントが多要素認証とSAML IdPサポート

　http://idmlab.eidentity.jp/2014/11/office2013-windowssaml-idp.html

[Windows10/AAD]OOBEでクラウド・ドメイン参加

※PIN入力がうまく行ったので少し追記しました。
※うまく行く条件が判明しました。AADのユーザの姓名に日本語があるとNGです。

先日の続きです。

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

先日は一旦LiveアカウントでWindows10にログインした後、組織のアカウントでクラウド・ドメイン参加をしましたが、今回はsysprep後の初期セットアップ中にいきなり組織のアカウントでログインします。
（先日のポストでうまく行かなかった部分のフォローアップです）


前提となるAzureAD側の準備は先日のポストと何も変わりません。

PC側の手順は以下の通りです。

①PCを初期起動すると、ライセンスキーの入力を始め、色々と設定を入れる画面が出てきますが、まず[Shift+F10]を押してコマンドプロンプトを起動します。

②そしてレジストリエディタ（regedit.exe）を起動すると、いきなり「HKLM\Software\Microsoft\Windows\CurrentVersion\OOBE\TestHooks」が開いた状態になっていますので、表示されているキー「TestBlockAadWebApp」を消してしまいます。

③PCを問答無用で再起動します。

④うまく行けば、「このPCを所有しているのは誰ですか？」と聞いて来ます。
　この画面が出なければ再起動を繰り返します。私は3回くらい再起動したら出ました。どうやらタイミングの問題の様です。

⑤ここまでくれば前回と同じなので、組織のアカウントでログインします。

⑥PCにログインした後、AzureADのユーザの情報を見るとデバイスが登録されているのがわかります。

ディレクトリ同期されている環境だと、このデバイス情報がオンプレミスのADにも同期されるようですが、現状はうまく同期されません。おそらく同期ルールがまだ対応していない、もしくはAD FSのDRSで拡張するオンプレADスキーマがクラウド・ドメイン参加のデバイスに対応していないんだと思います。

また、PCにログインした後、「クラウド体験ホスト」が自動的に起動してきてPINの登録が求められるんですが、これがやたらと不安定で、なかなかうまくPIN登録画面にたどり着かず、「Something went wrong」と言われてしまいます。
ここでPIN登録まで終わるとNGC（Next Generation Credentials）のセットアップ・フェーズが完了するはずなんですが、中々うまく行かないものですね・・・。

⇒試行錯誤していたらPIN入力画面が出てきました。
　関係性はわかりませんが、デバイス登録したユーザとは別のAADユーザでログインしたらPIN登録画面が出ました。
　⇒姓・名に日本語が入っているユーザだとダメなようです。Previewの間は英語名のユーザを使うしかありませんね。

PINを使ってログオンできるようになります。

尚、この状態だとVisualStudio OnlineについてはPCログインとブラウザログオンがSSOされるようです。（初回ブラウザ起動時にID/PWDを入力するとクレデンシャルが保持される仕組みっぽい）
※Cookieとか全部消すとやり直せます。
※Office365でも試してみましたが、こちらはまだダメでした。

今後に期待です。

[AD FS]Windows Server 2012 R2 Preview の AD FS ②

先日のポストに引き続き Windows Server 2012 R2 Preview での AD FS の話です。

今回は AD FS でデバイス認証を有効にして、ドメインに参加していないデバイス（今回は iPhone）で AD FS と連携したサービス（証明書利用者信頼として登録した Google Apps）へのシングルサインオンを行ってみます。

これは Directory Services の MVP 国井さんが紹介してくれているとおり、「BYODで活用されるデバイスの管理をActive Directoryから行える」という Windows Server 2012 R2 Preview の Active Directory の新機能を使って実現します。

国井さんの blog ポスト：Windows Server 2012 R2 PreviewのActive Directory(1)
- http://sophiakunii.wordpress.com/2013/07/02/windows-server-2012-r2-preview%E3%81%AEactive-directory1/


実現するには、まずデバイスを Active Directory 上に登録して、AD FS の認証をデバイスで実行できるようにする必要があります。

まずはデバイスを登録する。登録サービス（Device Registration Service/DRS）の認証は AD FS を使い、ドメインユーザで実行する。

AD FS でデバイス認証を行いアプリケーションを利用する。

デバイス認証を使うと登録されたデバイスではドメイン環境にある PC と同じように ID / パスワード等でのユーザ認証を受けなくてもアプリケーション（AD FS の証明書利用者信頼）を利用できるようになります。

実際に試してみます。具体的には以下のステップを実行します。
1.DRS を実行できるように AD FS を構成する
2.DRS を使ってドメインに参加していないデバイスを Active Directory 上に登録する
3.AD FS の認証手段としてデバイス認証を有効にする
4.AD FS でデバイス認証を受けサービス（証明書利用者信頼）へアクセスする


◆1.DRS を実行できるように AD FS を構成する

AD FS の役割を追加した状態でも最初から DRS が証明書利用者信頼として登録されていますが、サービスとしては DRS は停止しています。
この状態から DRS を実行するためには、
・デバイスを AD DS に登録できるように AD DS のスキーマを拡張する
・DRS が AD FS で認証するように構成する
という作業が必要です。

具体的には、PowerShell で以下のコマンドレットを実行します。

　Enable-AdfsDeviceRegistration -PrepareActiveDirectory

これで、AD DS のスキーマ拡張等の準備が整いますので、DRS を有効化します。

　Enable-AdfsDeviceRegistration

うまくいけば DRS が開始しているはずです。

◆2.DRS を使ってドメインに参加していないデバイスを Active Directory 上に登録する

次に実際にデバイスを登録します。
現状では Windows 8.1 および iOS が登録可能ですが、今回は iOS を使います。

iPhone の safari で https://＜AD FSサーバ＞/EnrollmentServer/otaprofile へアクセスします。
AD FS へリダイレクトされ、ユーザ認証が完了するとプロファイルがダウンロードされますので、インストールを実施します。

AD DS の拡張表示を有効にした状態で Active Directory のユーザとコンピュータを見ると Registered Devices というコンテナの下にオブジェクトが登録されているのがわかります。

オブジェクトのプロパティを見ると確かに「iOS」との記載があり、先ほど登録をした iPhone であることがわかります。

◆3.AD FS の認証手段としてデバイス認証を有効にする

次は AD FS 側の設定です。
AD FS 管理コンソールからグローバル認証ポリシーの中のデバイス認証の有効化設定を行います。（Windows Server 2012 R2 Preview からの新しいメニューです）

これで AD FS 側の設定も完了です。再起動なども不要です。


◆4.AD FS でデバイス認証を受けサービス（証明書利用者信頼）へアクセスする

では、実際にアプリケーションへアクセスしてみます。
今回は AD FS の証明書利用者信頼として Google Apps を登録してみました。
先ほどの iPhone から Google Apps へアクセスしたときに、デバイス認証でシングルサインオンが実行されれば成功です。

結果ですが、想定の通り初回ドメインユーザで認証を行えば2回目以降は ID / パスワードを入れることなくアクセスできます。（ブラウザを落として再度アクセスしても大丈夫）
デバイス認証を行わないケースだとブラウザを落とすと毎回 ID / パスワードを聞いてくるのでそれに比べれば非常に簡単なオペレーションになります。


尚、この状態を解除するには、
・iPhone 側でプロファイルを削除する
　⇒ユーザが自分でワークスペース参加を辞めたい場合
・AD DS 上でデバイスオブジェクトを削除する
　⇒管理者側が端末の利用を停止させたい場合
・デバイスに配布している証明書を失効させる
　⇒同上
などが考えられますが、こうなると System Center 等を使ったデバイス管理ソリューションと合わせて運用を行うことでよりセキュアで便利な状態が実現できそうな気がします。
また、多要素認証と組み合わせることで登録してあるデバイスでも追加認証が必要、というようなシナリオも考えられますし、今回は iOS で実験しましたが、例えば Windows RT のようなドメインに参加できないようなデバイスをビジネスで利用する、ということも考えられます。

しかし前回のポストでも述べましたが、Windows Server 2012 R2 では AD FS の役割がこれまで以上に大きな位置を占めるようになっているように感じます。TechEd や Build を見ていると AD FS を活用したシナリオが数多く用意されていますし、AD DS から AD FS への認証機能の大きなシフトチェンジが起きているような予感がします。
引き続き AD FS からは目が離せないですねぇ。

参考URL）
Solution Guide: Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications
- http://technet.microsoft.com/en-us/library/dn280945.aspx